Great idea. This would be useful.

@yafred The way this change was made (updating source string text) does not inform translators. It appears only in Crowdin's activity stream.

Are you comfortable that it's not necessary for existing translations to be re-worked to include this example please?
If you, either a new string can be introduced to ensure translators are notified, or I can delete the existing string and manually notify translators.

Edit: while you are at it, could you please also consider if this older rewording would need new translations too?
65d4482#diff-c122178f0679934c4884050732b3e155935ee6311e53dbf14d178599647b9cefL23

Thanks for the heads-up ... I'll keep that in mind in the future.

Whatever way we choose (crowdin or source code), there is windows where we loose the translations ?

Whatever way we choose (crowdin or source code), there is windows where we loose the translations ?

Not sure I totally understand the question. If you are asking whether we would have to lose some translations in order to change them - then yes, translators would be able to access the past string using the translation memory if it is close enough.

As a principle, if the actual meaning of a string changes, we should be introducing a separate string variable.

With that in mind, do you think these can continue to exist as-is or should they be recreated in source/have older translations purged on Crowdin manually?

If it's not too much work, I think it's better to do it on Crowdin ...

Let me explain what I was asking with an example:
1/ I want to update nvui.command1Description
2/ I create a nvui.command1Description2 and I update the keys in the source code
3/ If I run lila right now the French command1Description2 will show some English text

If it's not too much work, I think it's better to do it on Crowdin ...

Let me explain what I was asking with an example: 1/ I want to update nvui.command1Description 2/ I create a nvui.command1Description2 and I update the keys in the source code 3/ If I run lila right now the French command1Description2 will show some English text

It is a lot of work which is why I'm a bit apprehensive. 😅 It involves manually noting down who translated what to ask them to revisit the string, and there is no easy functionality to create a list of names to pass to Crowdin's message interface for instance. So I'd have to click through dozens of langauges, write down names, and then type them in manually to the 'Members' tab (as they must be contacted via the project, not directly, per on-platform anti-spam rules).

As an alternative, could the string be introduced in the code (in /trans/source plus any relevant Scala files), but not used on the UI yet?
Translators would then get notified.
You could create a separate PR to replace the UI string and merge it after giving translators ~2 weeks, when there are enough translations to justify it.

Too much work is a bad thing ...
So, for the case you have mentioned above, I can do the following things:
1/ Revert to the original English text for the existing keys and create new keys just for the translation process ... Pull Request 1
2/ When I see the translations coming back, I'll update the source code to use them ... Pull Request 2

Is it what you had in mind ... if yes, I'm ok with that

1/ Revert to the original English text for the existing keys and create new keys just for the translation process ... Pull Request 1 2/ When I see the translations coming back, I'll update the source code to use them ... Pull Request 2

Is it what you had in mind ... if yes, I'm ok with that

Sounds good, though I would also say you do not need step to revert the source English keys, you can just introduce the new keys.