nvaccess
Document the process for translators
Regardless of the documentation for a multilingual store, add-ons are translatable and this should be documented ASAP to avoid deletions or regressions, given that they are in fact translated, using the system created by @mhameed:
- Documentation, gettext messages and translatable mainfest keys could be sent to the system when a PR is approved or merged.
- Translated messages can be included in the add-on source code and binary and the corresponding commit could be automatically added to the submission repo, deleting the commit against it was created. This shouldn't require to be reviewed and maybe automatically posted on the store, if translations are sent periodically in a programed way as done now with automatic.crontab.
To start with, it will be more productive to be agnostic of translations. Translations can be stored in the addon repo, and be submitted with the addon as part of a version submission. Storing the translations in the addon repo means no extra steps necessary in this proposal, and also translations are available for the addon if it is distributed outside of the store.
Perhaps you are concerned about how this will affect the frequency of necessary addon submissions? Once we get a working prototype of this system, we can look at the "nice to haves" that speed up tedious or repetitive manual processes.
One thing that should be expanded on, is to point out that translated values for user visible strings will need to be returned by the endpoint for fetching addon lists. This is relatively straightforward, the thing that would be easy to miss here is that including the required presentation language code is necessary when calling the endpoint.
I am concerned about the frequency of submissions and also in case translations are not consideret at the same time of making the store available, affecting users of other languages. Otherwise, if you think that this issue is easy to consider, feel free to close it.
Enviado desde mi iPhone
El 10 ene 2020, a las 10:35, Reef Turner [email protected] escribió:
To start with, it will be more productive to be agnostic of translations. Translations can be stored in the addon repo, and be submitted with the addon as part of a version submission. Storing the translations in the addon repo means no extra steps necessary in this proposal, and also translations are available for the addon if it is distributed outside of the store.
Perhaps you are concerned about how this will affect the frequency of necessary addon submissions? Once we get a working prototype of this system, we can look at the "nice to haves" that speed up tedious or repetitive manual processes.
One thing that should be expanded on, is to point out that translated values for user visible strings will need to be returned by the endpoint for fetching addon lists. This is relatively straightforward, the thing that would be easy to miss here is that including the required presentation language code is necessary when calling the endpoint.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
How translations fits into this process is definitely something to consider. Though streamlining that particular reason for submissions can happen after we nail down the core process and have a demo system working.
