#How Joomla could do translations Joomla right now relies heavily on hand-crafted translation files that the translation teams are supposed to send in pre-assembled. This has several downsides, one of them being the missing versioning of the translations, the other the more than complicated way to keep the translations in sync. This document should describe a different way for how translator teams can do their work in a simpler way and how this could also fit in a future system of a distribution of Joomla.
###A central website for Joomla translations The first step would be setting up a separate website for the translations, which collects all relevant information. On this website, you can download language packs for your Joomla installation and translation teams can do the actual translations through a webinterface. This website could run under the URL translate.joomla.org. A big change to the current system would be, that translations would not be CMS centric, but translation teams would translate separate extensions and thus could also translate third party extensions.
###Tasks of this website
- Central download repository for translations for Joomla
- Central place for translation teams to hand in translations, either via webinterface or via an API
- Translation-repository for the available translations in the backend installer
###Features for the enduser A Joomla user right now has to download a new language and then install it in the Joomla backend. Normally, you only get the translations for the Joomla core and have to download separate translations for all third party extensions. With this new system, the enduser would only select the language that he wants to have available on his website and Joomla then searches the translation repository for all the extensions that the user has installed and automatically adds all available translation files. Installing language files through the normal backend install process will of course also be possible. The enduser either selects the language in the backend of his installation or he makes a selection on translate.joomla.org and downloads a customized package that he can install via the normal process in the backend.
###Features for the translators A translator can register a new language (which needs administrator approval) and then he can see all extensions (including the CMS extensions) which can be translated. The translator can import and export existing data via an API which will at least include file-upload, github and a connection to com_localise. Additional adapters can be included later on, like Transifex, etc. In the translator interface, the translators can then see a list of translatable extensions, choose one and then see all language strings that are available. In that list, you can see the language key, the english version, the current translation and on click an edit field to change the current translation. If in edit-mode, the program also tries to display where the key can be found. New keys and/or changed english translation are colour coded and can be filtered by. In the overview list, you can see equally colour coded, which extensions have been translated and which not and by which percentage. Translators can then mark a translation as finalised and release it as a new version. That automatically pushes this as a compiled INI file to github and updates all existing packages. Changes to the translation can either be send in via PR on github or via webinterface. We could either require every translator to authenticate with a github account and commit under their name, primarily in order to keep the statistics, or we could use one central github account and let Joomla handle this internally. It is expected of the translators to translate the text used for translate.joomla.org as a priority in order to keep that site accessible to as many people as possible.
###Features for the (third party) developers A developer can request his extension(s) to be added to the translatable extensions list. For this, the extension has to be available via github and the repository must adhere to certain standards, namely the folder structure. After approval, translate.joomla.org then parses the existing translations into its own system and monitors the github repository for changes. Translators then see those extensions in their list.
###Features for the administrator The administrator can register new languages, assign translators to those languages and approve extensions for translation status.
###com_localise com_localise would play a pretty central role in the translation process. It would have to be changed to be able to upload data to translate.joomla.org and provide the interface the translators would know from translate.joomla.org to the backend of an installed Joomla site, so that translators can see the translations in action and change them in the running system.
###Downsides Joomla has taken a special stand in regards to translations so far. Instead of keeping all the translations in a central repository, translation teams were free to host their completely own sites with the data and promote their own content on there. With this centralized approach, these websites would be superseeded and become unnecessary. The loss of public visibility might be a point of controversy in the community. Another point of conflict will be the rules on how an extension can apply for the translation status. Should these only be Joomla community maintained extensions? Can this be open for free GPL extensions? What about GPL extensions with a Freemium business model?
###Development The whole translate.joomla.org site could be developed based on the framework or based on a normal Joomla installation. While JIssues has done quite a lot of work in interfacing with github and based on this, it would be possible to create a site based on the framework, I tend to using a normal Joomla installation and implement components in there in order to implement this.