Planned Translation System Changes

[michaelDCurran]

this discussion outlines the planned changes to NVDA's translation system. Further questions can be asked here and we will provide answers and update this text.

Background

NVDA's current translation system is a collection of custom code that interacts with both NVDA's Github repository, and a translation Subversion repository.
The system currently handles NVDA translations, add-on translations, and the old add-on website.
The system is currently hosted on NV Access's main server (zebi).
The system was designed ~10 years ago, newer mainstream services are now available, and NV access and NVDA have grown significantly since then.

Problems

• The system is very fragile and breaks easily.
• For security reasons, the system can only be administered by NV access staff as it lives on the same server as other NV access infrastructure.
• The system is not welcoming to the wider software translation community, which means we are missing out on greater number of volunteers.
• NVDA translations and add-on translations are coupled together, which means there is a real risk an add-on translation related bug can break the processing of NVDA translations.
• NV Access is unable to provide the time / resources required and deserved by add-on translations, which is causing long delays for add-on authors.

Goals

• To isolate the translation system from NV Access's main server.
• To decouple the processing of NVDA translations and add-on translations.
• To use a popular mainstream solution for accepting / processing NvDA translations, ensuring stability and wider community exposure.
• To slowly deprecate processing of add-on translations by NV Access, assisting the community to move these to other mainstream solutions.

Planned Steps

1. Perform language freeze / release process for NVDA 2023.3, using the existing l10n server for translations.
2. Pause accepting / processing of translations for NVDA. Add-on translations will still be allowed.
3. Move translation system to its own isolated server. This server will be hosted by NV Access, but is completely unrelated to the main server (zebi).
   • This should be a fairly painless move, as no translation code depends on the main server, and all code is already under one user account.
   • Being isolated, NV access may again consider allowing 1 or 2 trusted community members to assist with translation system administration.
4. Create Crowdin project to accept / process translations of NVDA's po files, and ensure current translators can use the new system.
   • Translators should easily be able to download an up to date po file, translate with poedit, and upload for submission.
   • Translators will no longer be required to use subversion or any other revision control system to submit NVDA translations, rather they will either translate directly using the Crowdin interface and or poedit with po files from Crowdin. Note that add-on translations will still require the current subversion workflow until this is replaced.
5. Pause accepting changes to NvDA user documentation.
6. Convert all current NVDA user documentation to markdown.
7. Make all current NVDA user documentation markdown files translatable through Croudin.
   • This is the step with the most unknowns and the most changes to workflow for translators.
   • Crowdin can apparently scan markdown files and split them into translatable paragraphs. Translators can then either translate via the interface or exporting to po files. However, it is unclear whether we need custom code to regenerate the markdown file once translation is complete.
   • Instant html proofing will no longer be available. Though once the translation is pushed back to NvDA's github repository, it will be possible to view the markdown file on Github as rendered html.
8. Resume accepting changes to NVDA user documentation.
9. Perform language freeze / release process for NVDA 2024.1, relying on the Croudin system.
10. Deprecate add-on translation system, encouraging add-on authors to rely on other mainstream services or workflows to accept / process translations from the community.
    • Deprecation starts after NVDA 2023.3.
    • Deprecation means no new add-on registrations.
    • The service will be completely removed 1 year later or when all add-ons are off the system, which ever comes first. This includes hosting of add-on translations, and hosting of the old add-ons website.

Notes

• Some languages have not been translating the Changes For Developers section in changes.t2t, rather instead including a link to the English changes.
  • Link to English changes is good. How do we have this not appear in English though?
  • Is it okay to simply leave Changes For Developers section untranslated, or should this be split into a separate document?
• gestures.ini and characterDescriptions.dic for each language should be maintained via prs to NvDA's main repository. Reasoning for this is that these files don't change much, screen reader logic / behaviour changes based on these files so tech support needs to know, and translation is not a 1 to 1 mapping for these files.
• symbols.dic should most likely also be maintained via prs to NvDA's repository, though I would like to better understand how much this file differs across languages, other than the translation of symbol labels for existing lines? E.g. is it common for languages to change the flags on a line, or add entirely new lines not in the English version? If so, why?
• Key commands md and from that key commands html will be generated during NVDA build from each translated user guide md. However, we may wish to add a github action to the translations branch on NVDA repository which tries to generate and notifies if failed. Further research is required to understand Crowin's crequency of commiting to Github l10n branch.
• Checking syntacks of translated template strings in po files requires a github action similar to above.
• HTML proofing still needs to be researched further. It is unclear when the full translated md becomes available / how it can be accessed / downloaded, for possible local processing to html for checking.

[nvdaes]

@michaelDCurran , since you stated the following:

NV Access is unable to provide the time / resources required and deserved by add-on translations, which is causing long delays for add-on authors.

I agree with these plans. Also, I spend some time forking repos in the nvdaaddons organization so that add-ons can be registered in the system, and I'll contribute as much as possible to improve the add-on ecosystem, but if this task is not needed, for me this easier system is welcome.

I'm an owner of the add-ons mailing list and not a translator, so my comments will be focused on add-ons.
Some people, included me, discussed about this topic with Reef, and I know the existence of this old repo about the translation system. I think that it should be mentioned here for reference, to be deprecated or to take account proposals made there.
Also, should we consider this issue about add-on descriptions shown in English in the store here? May affect the system used to translate add-ons if, for example, the store uses json files instead of the generated manifests with localized info in different translations.
cc: @@CyrilleB79

[nvdaes]

Mick wrote:

◦ Crowdin can apparently scan markdown files and split them into translatable paragraphs. Translators can then either translate via the interface or exporting to po files. However, it is unclear whether we need custom code to regenerate the markdown file once translation is complete.

I've created a crowdin project and then I've translated 2% of a markdown file into Spanish. I've able to export the .md file to xliff format, which was opened with Poedit. After translating with Poedit I've downloaded the translated Markdown file. Of course this doesn't mean that NV Access can do the same since it maybe affected by the workflow used. I've done this via Crowdin interface.
I tried to add Cyrille as a manager of this testing project without success for now.

[nvdaes]

Mick wrote, about add-ons:

◦ The service will be completely removed 1 year later or when all add-ons are off the system, which ever comes first. This includes hosting of add-on translations, and hosting of the old add-ons website.

Though I agree with @CyrilleB79 regarding the benefits of a centralized translation service for add-ons, specially considering that Crowdin free plan hosts just 60000 words, as mentioned by @ruifontes, I think that, once the store is available in NVDA, the website can be deprecated. It's maintained by the translation teams, but sometimes is tricky to update the documentation there in addition to the add-on readme update, and I think that it may include even add-ons not available in the store, legacy, and the documentation available on the website may not be well updated in all cases. This is difficult to review and maintain, so sincerely I'd deprecate it when possible.

[zstanecic]

Hi Mick! Let me Comment on one planned action: 3. Make all current NVDA user documentation markdown files translatable through Croudin. • This is the step with the most unknowns and the most changes to workflow for translators. • Crowdin can apparently scan markdown files and split them into translatable paragraphs. Translators can then either translate via the interface or exporting to po files. However, it is unclear whether we need custom code to regenerate the markdown file once translation is complete. • Instant html profing will no longer be available. Though once the trnalsaiton is pushed back to NvDA's github repository, it will be possible to view the markdown file on Github as rendered html. I support changing the translation system, but it is a problematic move regarding the existing translation work: Some translators, for example Serbian, Croatian and polish, never translated changes for developers. To compensate for this, we added extra heading at the top of the documentation, i.e changelog to refer to the English changelog. Crowdin is good, as it will allow future NVDA translators to make translations via poedit only. What is suggest is to move out the developer changes from the user changelog to another place, because users should are rather not interested in reading things, what they don’t understand. There is also one unclear moment: How you plan to manage translating of symbols and character descriptions? I think, that this timing and plan is rather a draft, than a serious move. Translation is a serious process, and we need to watch out for it’s every aspect. In case of software, we are not talking just about translation of words, but of the whole interface adaptation to the particular culture. Best, Zvonimir

[michaelDCurran]

• gestures.ini and characterDescriptions.dic for each language should be maintained via prs to NvDA's main repository. Reasoning for this is that these files don't change much, screen reader logic / behaviour changes based on these files so tech support needs to know, and translation is not a 1 to 1 mapping for these files.
• symbols.dic should most likely also be maintained via prs to NvDA's repository, though I would like to better understand how much this file differs across languages, other than the translation of symbol labels for existing lines? E.g. is it common for languages to change the flags on a line, or add entirely new lines not in the English version? If so, why?

[CyrilleB79]

Hello Mick and all

First of all, I fully understand the need to make evolve the translation system and I agree with all the reasons given to explain the need of such an evolution.

Here is my first feedbacks and thoughts on this announcement.

NVDA files to translate

As listed in the NVDA translation wiki, the files to translate are the following:

nvda.po

no problem

change and user guide t2t files

Keyboard shortcuts file

How will keyboard.html be generated? Will you write a dedicated script to replace the t2t macros?

Instant generation of html for proofing:

Instant html proofing is a common use case, at least for me. Having no ability to check immediately the result of the changes will lead to less efficiency and loss of time in the translation process due to task switching / splitting: if I have to check my work one day later, I have to switch again to this task and remember specific points to check.

• How often will the translation content be merged in NVDA Git repo? Merging as often as possible in NVDA repo would be optimal for translators to check their work. On the opposite, merging too often may flood the Git commit history and degrade NVDA developeres' use of Git history.
• Will there be regular snapshots of the beta branch or better, artifacts generated from NVDA's Git repo so that translators can check their work?
• What is the estimated maximum time a translator will have to wait to be able to see the result of a submitted translation? One week is clearly too long.
• Are we sure that there is no possibility to generate the html before the source t2t file lands in NVDA's repo? Implementing this possibility (even in a second stage) would be a plus.

Conversion

Are we sure that current structure of the user guide (and change log) matches the English one? Will we be able to pre-fill the .po files with existing content? Or may we encounter structure problem?

I know that some languages do not exactly follow the English user guide in some cases and have added country specific information. May this cause issue when converting the data?

Some languages are a bit (or a lot) outdated. What will happen to the languages that will not provide translation for 2023.3 release? Will they be dropped from NVDA? Or will NVDA build process support t2t and md conversion in parallel during a certain transition period? Or will the html files be committed in NVDA's repo until a .md file is provided?

Changes for developers

Change for developers are not translated in all languages, but in some of them they are. French is one of them and French developers usually appreciate to have localized content when possible. Please keep the possibility to translate them for those who want to.

characterDescriptions.dic and symbols.dic

How will they managed? Character file is not updated frequently and can be updated through issue/PRs in NVDA Git's repo; but symbol file is updated quite more often from time to time.

gestures.ini

How are they managed? The changes are not so frequent so if no solution is provided, direct issues/PRs in NVDA's repo can be done

locale.t2tconf

Will translators still be able to define text direction and to use some locale variations (e.g. post-processing for numbers in Arabic) If no, how will the specificity of current locale.t2tconf files be honoured? Also will the language of the generated html files (User Guide, Change Log) still be honoured?

Checking the files provided by translators

What about various checks made by the current translation system? I'm thinking to the following but there may be other ones:

• checkPo script to check the validity of nvda.po file, that is general structure of the file and check that translated strings use the same formatting placeholders as the source string.
• User guide structure difference (generating userGuide-structureDifferences.txt): I imagine that the .po file generated from the .md file should guarantee an identical structure.

Add-on translation

The centralized translation system is very efficient for translators who translate many add-ons: there is only one place (the SVN repo) where all happens for them. They can easily see in one or two locations (the settings file in SVN repo and the translation status page) what can be translated or needs to be. I understand that NVAccess cannot and will not provide and maintain such system in the future. But if you could give your opinion and even design hints for a future system that could take advantage of the centralization around the community, that would be very nice.

If a centralized translation system is not offered by the community, I am not sure that the amount of translated content (number of translated add-ons, of languages and of strings) will grow with respect to the old system.

Thanks for reading me.

[nvdaes]

Re add-on translation:

Add-on translation
The centralized translation system is very efficient for translators who translate many add-ons: there is only one place (the SVN repo) where all happens for them. They can easily see in one or two locations (the settings file in SVN repo and the translation status page) what can be translated or needs to be. I understand that NVAccess cannot and will not provide and maintain such system in the future. But if you could give your opinion and even design hints for a future system that could take advantage of the centralization around the community, that would be very nice.
If a centralized translation system is not offered by the community, I am not sure that the amount of translated content (number of translated add-ons, of languages and of strings) will grow with respect to the old system.
Thanks for reading me.

I agree. From my side, since Mick mentioned Crowding and I'm interested not just for add-ons, I'm planning to investigate Crowding in my GitHub account including several add-ons in an unique project. We may use nvdaaddons organizations created by @josephsl , its primary owner if needed and he agrees.
Crowding GitHub integration supports various repos in a single project.

@michaelDCurran Also, as a possibility, if NV Access server won't be different and you're considering to grant access to one or two community members, if needed, you may consider to create a subfolder for add-ons there, just if this was needed. Maybe enough with nvdaaddons organization. I'll try to investigate about fileformats in case the add-on template needs to be modified too, for example generating json instead of ini files in future, to see how well are supported and accessible in Crowding.

[nvdaes]

I've created a project on Crowdin. @CyrilleB79 , the progress of translation seems to be shown as percentage. If you or other ones want to participate in this investigation, I can invite you. I'll send you an invitation @CyrilleB79, if I can, in case you want to take a look.

[nidza07]

Hello,
I'm the person currently responsible for the Serbian NVDA translation.

In principle, just like all the others, I agree with the outlined proposal.
However, managing documentation could really be problematic. Not only do we not translate changes for developers, as said above, but there is also another thing to consider:
The Serbian translation of the changes file has started only since 2017.2. This means that if we convert the changes file to markdown and directly take the English source Markdown file and convert it into a translatable po file, we'll have a lot of missing translations for very old versions, which would be completely pointless to translate at this point in time. I imagine most languages will have this issue, so I hope a solution can be found which will be efficient on your side as well.

[michaelDCurran]

@CyrilleB79
• Key commands md and from that key commands html will be generated during NVDA build with a script from Scons from each translated user guide md. However, we may wish to add a github action to the translations branch on NVDA repository which tries to generate and notifies if failed. Further research is required to understand Crowdin's frequency of committing to Github l10n branch.
• Checking syntacks of translated template strings in po files requires a github action similar to above.
• HTML proofing still needs to be researched further. It is unclear when the full translated md becomes available / how it can be accessed / downloaded, for possible local processing to html for checking.
• The new system would see the structure of all markdown files (user guide, changes etc) be the same in all languages. I acknowledge this is a difference. However, if we can identify some common patterns across language files, such as a per-language paragraph at the beginning with a specific welcome or contact info or what ever it is, then we can by all means include that bit of structure in the english markdown so that it can be translated as the language maintainer sees fit.
• Re gestures.ini, characterDescriptions.dic and symbols.dic: they would be maintained via prs to NVDA's main repository. See notes in main discussion text for reasoning why so far.

[ruifontes]

@nvdaes the 60 000 words limit will not be a problem for users with lots of add-ons or with big add-ons?

[nvdaes]

Maybe. I have seen a Github action which maybe included in each repo to synchronize translations, and this maybe better than using a unique project and this limit may not apply. I"ll investigate more tomorrow.

[nvdaes]

Hi again @ruifontes, I think you're right. Just seen that the maximum words per free plan is 60000 words (per account). Then I suppose that each person should host their own projects creating an account. I¡ll investigate the mentioned GitHub Action as well as the GitHub integration

[zstanecic]

Hi, As i have read on the crowdin site, they offer free licenses to open source projects

[josephsl]

Hi,

Since I'm mentioned: I have retired from NVDA code contributions and translations workflow - at least retired from actively contributing to it, and I will follow whatever plan the community comes up with. If Crowdin seems to be a suitable way to bringing in more add-on translations (including those hosted by NVDA Add-ons organization), then let it be done.

Thanks.

[Adriani90]

@michaelDCurran before converting the user docs to markdown, maybe we should check this:
https://docs.gitlocalize.com/file_formats.html

They don't support t2t yet, but it might be worthwhile to contact them. i think at least for the NVDA translation it would be nice to have it all on github on just one interface.

[michaelDCurran]

GitLocalize seems very similar to Crowdin with its feature set. Though I get the feeling that Crowdin is probably used a bit more. I originally went with Crowdin as there are other successful open source projects, with blind contributors using that platform already. However, we can't start actually making the move until the NVDA 2023.3 cycle starts, so we still have probably at least a month to decide. I'm certainly keen to hear experiences from people using both platforms.

[dpy013]

GitLocalize seems very similar to Crowdin with its feature set. Though I get the feeling that Crowdin is probably used a bit more. I originally went with Crowdin as there are other successful open source projects, with blind contributors using that platform already. However, we can't start actually making the move until the NVDA 2023.3 cycle starts, so we still have probably at least a month to decide. I'm certainly keen to hear experiences from people using both platforms.

hello michael
The recommendation is to use crowdin
Currently osara is also using crowdin and he is running it fine.
so this information may help you.

[dpy013]

Also, crowdin's default translation editor screen reader support is very good.
So this gives translation maintainers who don't want to use poedit more options for maintaining translations.

[nvdaes]

I'm not a translator of NVDA. My relationship with the translation system comes from add-ons, since during a while I had access to servers for add-on registration. But I have contribute translations for other projects and I tried GitLocalize. Unfortunately, with this system I couldn¡t export a .md file to translate it with Poedit, and I was able to do it with Crowdin.
Of course this is not a complete comparison, but this is the experience that I can bring up here.

[LeonarddeR]

I really like this proposal. Some random thoughts:

1. The dutch what's new also contains a reference to the English changes document for the developer changes. I'd vote for moving the changes for developers into the developer guide, bundling the developer guide with every release and add a link to the developer guide to the help menu.

2. Will there still be a weekly merge from crowdin to a particular branch on github (e.g. beta)? Personally I'd change this as follows:

   • Change the weekly cadence into a daily or even hourly one
   • Use a separate branch for translation work based on beta, but not equal to beta
   • Merge that branch into beta every week

   The inability to proofread HTML seems a bit concerning to me.

3. I'd like to discourage any attempts to stick to txt2tags. Even now we are not on the most recent version, and version 2.6 (the newest) is already really old.

[zstanecic]

Hi, Why translator should proofread html? Translation process should become more straightforward, as defined by Mick. If we get to localize / translate the text, we should do it without tags. At least we should stick to markdown and convert this from .po to markdown, and then from markdown to html. From: Leonard de Ruijter ***@***.***> Sent: Tuesday, July 25, 2023 6:05 PM To: nvaccess/nvda ***@***.***> Cc: Zvonimir Stanečić ***@***.***>; Comment ***@***.***> Subject: Re: [nvaccess/nvda] Planned Translation System Changes (Discussion #15014) I really like this proposal. Some random thoughts: 1. The dutch what's new also contains a reference to the English changes document for the developer changes. I'd vote for moving the changes for developers into the developer guide, bundling the developer guide with every release and add a link to the developer guide to the help menu. 2. Will there still be a weekly merge from crowdin to a particular branch on github (e.g. beta)? Personally I'd change this as follows: * Change the weekly cadence into a daily or even hourly one * Use a separate branch for translation work based on beta, but not equal to beta * Merge that branch into beta every week The inability to proofread HTML seems a bit concerning to me. 3. I'd like to discourage any attempts to stick to txt2tags. Even now we are not on the most recent version, and version 2.6 (the newest) is already really old. — Reply to this email directly, view it on GitHub <#15014 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVCDE25BKQSMDF5ESDSVGTXR7VBHANCNFSM6AAAAAAZIQKY3M> . You are receiving this because you commented. <https://github.com/notifications/beacon/ACVCDE5EA66METEYFP3Z3FLXR7VBHA5CNFSM6AAAAAAZIQKY3OWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAMPJSM.gif> Message ID: ***@***.*** ***@***.***> >

[LeonarddeR]

we should do it without tags

I don't think markdown translating will work entirely tagless, i.e. with inline links pointing to other areas in the translation. I guess that's something we'll find out.

[zstanecic]

Ask Tw blue developer, he did it tagless somehow. I don’t recall his name correctly. From: Leonard de Ruijter ***@***.***> Sent: Tuesday, July 25, 2023 6:28 PM To: nvaccess/nvda ***@***.***> Cc: Zvonimir Stanečić ***@***.***>; Comment ***@***.***> Subject: Re: [nvaccess/nvda] Planned Translation System Changes (Discussion #15014) we should do it without tags I don't think markdown translating will work entirely tagless, i.e. with inline links pointing to other areas in the translation. I guess that's something we'll find out. — Reply to this email directly, view it on GitHub <#15014 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVCDEZIVJELEJW44FVQJA3XR7XZNANCNFSM6AAAAAAZIQKY3M> . You are receiving this because you commented. <https://github.com/notifications/beacon/ACVCDE2TQUVTKOKYORJGB7LXR7XZNA5CNFSM6AAAAAAZIQKY3OWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAMPJ5G.gif> Message ID: ***@***.*** ***@***.***> >

[dpy013]

I just saw it at crowdin.
NVDA dashboard in Crowdin

[michaelDCurran]

I have in deed registered NVDA with Crowdin, but it is not actively processing translations. We will not start doing this until we pause the current translation system framework once 2023.3 has been released.

[michaelDCurran]

An update on this plan:

• We decided that as 2023.2 was such a large release, that we would then allow for 2023.3 to be a much smaller but quicker release, which could address any known issues from 2023.2. At time of writing, 2023.2 has just been released, and we have already branched for beta of 2023.3. This means however that we have delayed the translation system work until after 2023.3. As previously mentioned, there will be no 2023.4 though, thus the translation system changes will occur in a much larger gap at the end of this year between 2023.3 and 2024.1.

[michaelDCurran]

Current status update:

• NVDA is now on Crowdin: https://crowdin.com/project/nvda
• All languages supported by NVDA have been enabled in Crowdin and have been appropriately mapped where possible so that exporting matches our existing locale file structure.
• the nvda.pot (gettext source strings file) generated from the beta branch has been uploaded to Crowdin and is therefore ready for translation.
• For NVDA 2024.1, the plan is for NV Access to periodically update that file manually, and export the translations and commit back to the beta branch manually. That is a very simple process. Once we are happy that Crowdin has successfully worked for 2024.1, then we will look at automating that process via Github actions.
• We will start inviting translators / proof readers over the next little while (see questions below) and then translators will be free to start translating at will. Of course early next year we will call a translation freeze as usual which will give translators appropriate time.
• Once translators are underway with translating / approving strings for nvda.pot (gettext), then we will move to the next stage which will be to convert our user guide and what's new document from t2t to markdown, and make those available for translation via Crowdin as well. But, I only want to start that process once we know that the process is working okay for NVDA gettext strings.
• Plans / considerations are still underway for the add-on translation system, but NVDA core translations are our priority right now.

Questions:

• General accessibility of crowdin is lacking. E.g. unlabelled Approve button. Is this acceptable? How have blind translators on other projects coped with this so far?
• Are there a couple of people within this group willing to take on the role of Project manager for the NVDA project in Crowdin? this would involve managing permissions for translators, answering questions etc. Please contact me if interested.
• NVDA has a list of one or more translators for each language from the existing NVDA translation system. What permissions should these people have? I would imagine that since they all previously had access to svn, then giving them all translator + proof reader (ability to approve) would be suitable? Note that anyone else from the public can join as a translator, but would not be able to approve.

[Adriani90]

Mick thank you very much for this change, I think now it will be easier to delegate translations and increase active contributions in local communities.
Your write:

What permissions should these people have? I would imagine that since they all previously had access to svn, then giving them all translator + proof reader (ability to approve) would be suitable?

Yes that's very important in my view for them to have translations and aproval rights in the first step since these people maintained the translations for a long time now.
Is it actually possible for the translators to change the status of another translator of the same language? Let's say we decide in the german or romanian community who is translator and who is approver at a later stage, can we adjust that by ourselves?

Once translators are underway with translating / approving strings for nvda.pot (gettext), then we will move to the next stage which will be to convert our user guide and what's new document from t2t to markdown, and make those available for translation via Crowdin as well.

That sounds really nice. We probably also need to add symbols.dic and the gesture configuration file which documents key commands in other languages as well right?
We had actually a very constructive discussion on converting t2t to something else, and at least me I was stuck because I didn't find a way to automate things like generating key command references or something like that. FYI, here is the discussion in #8734 which I have reopened for now.

[michaelDCurran]

I don't believe proof readers can upgrade or downgrade translators. However, Project owners or managers can grant language Coordinator status to one or more people for a particular language, allowing them to manage proof readers. Thus why for now I have asked for a couple of people to volunteer as Project managers for NVDA on Crowdin, so that they can initially manage permissions, and perhaps hopefully identify one or two primary translators from each language to become language coordinators. Message ID: ***@***.***>

[chojiro]

Should I currently expect some strings to show up as untranslated, even though it is fully translated on SVN, aside from potentially newly added strings? I don't really want to touch it unless I know for sure. I'm assuming translators can start translating at will after they've been invited to the project. I should probably clarify that these strings were translated previously.

Also, in some cases language maintainers probably haven't been very active. Some languages obviously have more than one translator, so identifying one or two people for each language as a coordinator would probably be ideal. Maybe partially based on contributions/activity? This approach could streamline the process and ensure a more efficient and consistent workflow and prevent discrepancies. Granted, It's been years since I used Crowdin, but I'm assuming a proofreader's translation is skipping the approval process by others. That's how I remember it, anyway. So, anything submitted through PoEdit would similarly be submitted for either approval or immediate publication.

[CyrilleB79]

Hello

FYI, I have opened 2 issues regarding translation: #15934 for unmodified strings that need to be translated again (e.g. braille role abbreviation"), and #15933 for old source and translation text not available anymore.

[nidza07]

@michaelDCurran As a Serbian translator, I was invited to the project, but after the changes made as a result of #15943 Serbian Cyrillic is now correctly marked as Serbian Latin, but I am no longer able to approve the translations for this language. I have updated the translation but the changes are listed as needing approval, so could you check and, if necessary, grant me the proofreader status again?

Thank you.

[michaelDCurran]

@nidza07 When inviting everyone, I believe I had correctly invited all email addresses from the old system associated with 'sr' to Crowdin for Serbian Latin. It was only the original upload which was incorrectly auto-identified. If you still do not have correct approval permissions, please let me know your username on Crowdin and I shall double check your access.

[nidza07]

I believe everything works correctly now. Not sure why the strings weren't approved yesterday even though I checked the checkbox to auto approve new translations, but now that no longer seems to be an issue. In case it happens again in the future I'll get in touch.

[DraganRatkovich]

Hello,

@michaelDCurran Please change my role to translator/proofreader for Georgian language to begin translating and approving uploaded or modified Georgian translations. My username is DraganRatkovich on Crowdin

[slanovani]

Hello MR. Curran, I'm from Colombia, and I used to be a translator for spanish colombian variant of NVDA, but I stopped translating because I didn't feel comfortable with the old system. But now that NVDA translations will be handled in Crowding. I'd love to contribute with my translations as much as possible, since it's much easier for me to sinchrhonize with crowding and Poedit. I'm Slanovani on Crowdin.

[jmdaweb]

Definitely It's not a good idea. The colombian spanish translation has always been a copy of the general spanish translation with a few words changed and, finally, with no updates. Multiple users have configured it accidentally, finding most interface in english and untranslated add-ons. This caused a bad impresion about NVDA and, finally, those users switched to other screen readers. In my opinion, colombian spanish translation should be removed. The currently maintained spanish translation is enough for everyone. Despite spanish has a lot of variants around the world, they are similar enough to require only one translation.
Regards.

[slanovani]

You're right, my friend.and I admit I'm guilty for that to happen. In fact, until a few months I was also thinking the same. I mean, that the colombian variant should disappear. But as I said, My main reason for not continuing to maintain this variant was because I didn't feel good wit the Assembla and subversion system.
However, now that the project is moving to Crowdin, it's' a thousand times easier for me to dedicate to it. Curran says in his first post that uncomftability with the old system was the reason for losing translation volunteers, and I felt identified with that cause. I consider that it's easier for me to work via Crowding because actually NVDA is not the only project i've worked on via that platform, but also others like easy voice recorder for android, the discontinued f123 access addon for Firefox, and even Mastodon.