Improve the work process of translating an application after modifications

[lionelberton]

Here is my understanding of the current work process of using resx translator:
The first time you want to translate an application, you point to a folder containing neutral language resx files. You create new languages as necessary and you provide translations for all the red lines.

Next time, after some new keys added or removed, you open resx translator again and you provide missing translations for red lines.

However, if there were only textual changes of the neutral language string, you have no indication whatsoever.
What is the recommend work process for this task?

A way could be to put brackets [] around the neutral string, so that it becomes red as if it were untranslated, but it assumes that I need to perform the whole translation of all languages, then remove the brackets, before I can do any release. for very small apps it is workable but when many peoples are involved, it does not sound right.

An idea could be to put in the comment part of the other languages, the original string of the neutral language. This way, you could know at any time if the translation is still valid or if it is probably invalid because based on a different neutral string. you would put this string only when the translation of a particuler key is modified, so that translation can be done in multiple times.
This assumes that the comment is only coming from the neutral, and is useless in translated languages.
At the same time you could make a release at any time, independently of the status of translation.

What do you think?

[NLindbom]

Correct me if I'm wrong, but I don't think there is a set process for such a task. I assume you have different people working on the different translations.

Personally I am against using the comment field of the neutral language for anything but comments. In my case it is used for naming formatting parameters e.g.: Neutral: "[Greeting] {0}", Eng: "Hello {0}!" and comment "0 = name". And hence, I'd advice against using it for metadata.

You could, for instance modify, the program to allow for the user to mark cells as not translated and show them as red until the cell has been edited and store these "tags" in a separate metadata file that can be checked in with the rest of the project.

[lionelberton]

True, I don't think there is any, but shouldn't there be one?

Well, in restranslator view you have a single comment field, so what would be the interest of storing it in every language file? Storing it in neutral is enough, and there is an option for this luckily.
So that free up the comment field in every alternate language file, and this is precisely where we would need to store the original text.
In a full resxtranslator work process that would work. And it could be an option that you could disable if you want to have a different work process ?

Using a separate file would work as well, but it is again another file to manage. What would be the rationale for that?

[NLindbom]

It would work, but the rationale is that it doesnt seem right to store data in a comment field :) And I don't think saving a tool-specific file in a project would be that farfetched, seems like a small "cost".

On the other hand both of these solutions could be made entierly optional (and probably should be) from a setting.

And last, I don't think I am the right person to decide what goes into this project just trying to give my perspective. Would be happy to hear others input, maby im beeing "purist" about this for no reason. You can always fork the project and modify your own solution, worst case you would have a tool that works perfectly for your team!

[Klocman]

I think this is a good idea, just want to hear some opinions before working on it.

I think it would be best to use a separate file, but should it be one file per resource, or one file per directory?
Should this file be only for local use, or distributed with the resource files?

Another possible solution would be to use metadata, but I'm not sure if it would stick around when changing the resource in visual studio or other editors.

[lionelberton]

Ok for separate file.
I would prefer one file per resource file because each language is translated by a different person, so when merging each other changes, it is simpler to take all the files rather than merging them.
It is for the sake of versioning the translation process, so it does not have to be distributed in the release. However, it needs to be distributed to the translators.

In latest visual studio, any unsed data is stripped out on save. Even after modifiying the xsd schema, I could not get it to work.

[pauloya]

Have you considered clearing all translations when modifying the neutral text?
Or creating a new token when any modification is done? e.g: "Intro" becomes IntroV2
I think ResTranslator deals well with missing translations, so translators can just work on the missing ones.
I'm also looking at this tool that helps clear un-used resource entries in the code:
https://github.com/microsoft/RESX-Unused-Finder

[enagora]

Thanks, by the moment is enough for me, I have no so much free time. if you want you can add and create a pull request.

…

On Fri, 18 Oct 2019 at 11:10, pauloya ***@***.***> wrote: Have you considered clearing all translations when modifying the neutral text? Or creating a new token when any modification is done? e.g: "Intro" becomes IntroV2 I think ResTranslator deals well with missing translations, so translators can just work on the missing ones. I'm also looking at this tool that helps clear un-used resource entries in the code: https://github.com/microsoft/RESX-Unused-Finder — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#30?email_source=notifications&email_token=AFQEK7JJC6LXXKYGEAXPZVLQPF4PBA5CNFSM4FBQVHEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBTPOVQ#issuecomment-543618902>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFQEK7II7UICQSFHSECH4KTQPF4PBANCNFSM4FBQVHEA> .

[pauloya]

My proposal requires no changes on the software, I don't think. Simply a change on the process.