Option to revert modified interface string translations to Base

[pilky]

Problem Statement

Sometimes you need to update a string in an interface file that has already been translated. This necessitates updating the that string in all translations. However, interface strings are keyed to the object ID, so if the object itself doesn't change then bartycrouch only seems to update the comment, but leaves the actual localisations untouched. This requires developers to be extra careful in auditing the changes

Suggested Solution

Bartycrouch seems able to detect that the string has changed in the Base localisation by the fact that it updates the title. It would be useful if there was a configuration option to also have it replace the localised string with the new Base localisation, as the localised string is likely now invalid. This would make it easier for translators to see that the string needs to be re-translated

Example Usage

You have a button titled "Delete" in a NIB with translations in multiple languages. You update the button in the NIB to "Remove". The next time you run bartycrouch update all strings files for that NIB get updated with "buttonID.title" = "Remove", replacing any previous translations for buttonID.title.

Possible Involvement

• I could help with implementation: Depending on time I could take a look at implementing this myself, though likely not in the near future
• I could help with testing: Once implemented I could assist with testing on my current project to ensure it works

[Jeehut]

@pilky Thank you for this idea. But I do not understand how this is useful yet. For example, in your above "example usage" you are updating the "Delete" base translation to "Remove". Imagine the German translation was "Löschen" before you made the change. I don't understand how it's any useful now to replace the German "Löschen" with the English "Remove" value.

The reason we update the comment is exactly the purpose you are asking for: Translators can then see the updated English term. But what workflow do you have that it would be more useful to replace a valid translation with an updated base value?

[pilky]

@Jeehut Comments are easier to overlook, partly by being comments, but mostly by being in the same language before and after the change.

The reason for wanting the string translations to be reverted to Base is that it is a bigger "error" and so easier to see. The translator doesn't need to check every string in the file each time and make sure the translations are still valid, they just need to look for untranslated strings.

They'll also show up when you build and run the app, which means developers and QA can more easily find any changed strings that haven't been updated. You don't need to know the language the app is running in to find an untranslated string, but you do need to know it to find a string that hasn't been updated (on top of knowing it was updated in the Base locale).

Essentially it makes the process of translating the same for both new and changed strings (i.e. look for what isn't translated)

[Jeehut]

@pilky Thank you for explaining that to me, it does make more sense to me now. So what you're asking for is only relevant if you use Base-translation, which is not used directly in the first place. And what you want as an option is something like a "override all translations with base value if base changes", right?

This should be possible and I would accept a PR that implements this and documents the new option in the README. Feel free to tackle it if you have the time to. To me, it currently seems like a very specific workflow that smaller companies don't need and most larger companies handle in a different way, e.g. by using a proper translation service where they can mark a specific translation as "needs review" in such a situation. Therefore I will not put much energy into this myself, but I would review any related PRs. :)

[pilky]

@Jeehut Thanks. Unfortunately I don't have time to implement it right now but it's good to know you're open to the functionality. Hopefully when I or someone else on my team has some more time we can get it implemented and a PR up.