It is complicated to have all translations done on time for the release.
And for new translators it may take too much time before seeing the result of their work because we are expecting a good percentage translated before including them in the release.
Also we may have some fixes to apply for translations after the release. For now it is forbidden by the no data modification policy. But indeed translation update is not that critical even for a production environment as we allow to modify them from the UI.
Proposal
We make a branch for each series on Tryton / Translations · GitLab then we create a translation project per branch on https://translate.tryton.org/
We remove the po files from the repository and instead we put a url file in each locale folder which provides the URL to fetch the po file by formatting it using series and language.
The po files are frequently extracted from the repository and put on https://downloads.tryton.org/ (and the CDN). trytond is modified such that when loading a translation if the file does not exist in the locale folder of the module and if an url file exists, it downloads it and use load it.
To build the docker image, the translations for a set of language that are considered as fully supported (which means that the translators reach 100% on each release) are pre-fetched.
This design will not apply to tryton and sao packages because they need to be processed.
So the release script will be updated to fetch and compile the translation files when building the packages.
The language definition from trytond/ir.lang.xml will be defined as noupdate and update process will be based on the language code instead of the database id. This way user could create the missing language if needed and it will not create issue when the language is added in standard.
The loading of translations will have a separate flag in trytond-admin such that it will be possible to load only the translations.
In case of a new language which branch must be translated?
What if I just start translating the LTS series but not update the translations to newer series?
Why not fetching all the translations in docker images? This will mean that the docker image will contain all the latest translations for all languages and one can start translating from a released series to deploy the newly translations.
One starts translating in 7.0 series while newer series are released. How we move the translations to newer series?
The fact that translations are updated on demand may discourage translations (I tought doing it) to not translate the application to 100% because missing translations can be added latter on demand. Not sure if this is what we really want.
What is partial translations for you ? Because for me w are already releasing partial translations as we have some languages that are not 100% translated which means releasing partial translations. See for example:
Plese note that I have nothing against partial translations as tryton is a modular system and people may be interested on just translating the modules they use.
100% of what? 100% of the component or 100% of the full project?
You propose to just include in docker images the translations for the series that are fully translated (100%) and do it on every build? So the docker images will be filled with the translations when a languages reach 100%?
Latter you propose to download the translations each time the server is loaded. But which translations? All no mather its state or just the ones with 100%?
I do not understand which is the rational to not include the translations in the docke rimage but force the server to re-download them each time the image is started (which will mean each time a new image is deployed in any server).
I must be missing something because that seems to not make so much sense.
My fault, you said when loading the translation the file is downloaded. Thanks for the clarification.
For me having a mechanism to download translations and storing them on a cdn sounds like overenginering.
Won’t be simpler to just include them on the released packages? This way when the translations are loaded the latest version will be used having the same efect.
Also it will be possible for the user to update the transaltions on a bugfix series if needed/desired.
It does not seem to much complex to update the release scripts to work this way.
This will also have the benefit that translations can be updated for released series without any need to alter the server code.
What is the status of this proposal? I think it would be a great thing to accomplish. Many projects have the concept of “language packs” and this goes in that direction.
But if we go ahead and move the locale outside the package, people still could be able to download it and install their packs. I might be missing something, but seems more of a project management decision than a technical one.
I think it is extremely important that translations are made available to users in the same straightforward manner as they are curently. Therefore, the technical aspects should definitely be clarified before the project decision is made. Simply telling users that they can download the translation is certainly not conducive to the user-friendliness of the project. Relying on external, possibly failing or unavailable sources for language downloads is already a disadvantage of the proposed solution that should IMHO not be underestimated.
I agree the translation process should be both simple and accurate. It is also important to rely on the sources to download.
We can rely on the translation sources in the same way we rely today on the sources of the kernel.
The concept of “language package” will provide a much lighter, modular and scalable approach. In my opinion it will make life easier to the end user and the translation teams.
I don’t think, that this comparison targets the correct issue. The download of sources is a different issue from download/availability of binaries/compiled language files.
If you are not able to download the sources of the kernel you usually are still able to work on your system (at least if you use a distribution that distributes binaries). If you are missing the kernel itself you are simply stuck.
The same applied to language files means: If the compiled language files are not available at the time of installation/activation/upgrade they will have to be fetched at a later time which will require a manual action of the administrator. Until then the system will remain in a possibly untranslated or may be even incorrectly translated state. And let’s not forget the machines without access to internet for various reasons.
This all only to show the possible disadvantage of the external download solution.
You bring up a good point, about being able to do the core installation process in your own language. They could be fetched automatically when Tryton installation wizard asks for the language.
In my opinion, the concept of language pack will be the best approach, as in the case of Libreoffice or Firefox.
