are just obsolete, but they are considered missing, for example "debugstringids_desc,core_admin".
Sorry, but as far as I can track, there is nothing wrong with this string. It was introduced as a replacement for the legacy [configdebugstringids,core_admins] and it is reported as missing string correctly.
Of course there can be some inconsistency in the AMOS repository (although there are several mechanisms how to prevent them) but I can't see anything obviously wrong right now.
David thanks for the clarification, got it! Just a question, when a string is replaced, there is a way to find the replaced string translation ?
No, unfortunately there is no easy way how to connect those two strings automatically. If the string sounds like something you think should already be translated, look at the string timeline (the +- icon) and copy the Git patch hash that introduced it. Then go to github and see the string change in context. Hmm, that reminds me that the Git hash could actually be a link to github automatically.
This is a cool improvement, in gthub it is possibile to see what string has been replaced, and search for it. Thanks!
For the future, could it be possible to think at something able to show the replaced string (if any) with it's translation ?
something able to show the replaced string (if any) with it's translation ?
Well. If we move or rename strings identifiers without changing the string text itself, we use so called AMOScript in the commit message that instructs AMOS to execute the same change in all language packs. You may not even notice it but a significant amount of strings were already moved in AMOS (it is possible to use AMOS Log feature and find all commits with the source 'amoscript' that affected your language). In 1.x times, whenever the string was moved or renamed, translators had to re-translate it so this is really huge improvement.
However, when a string is replaced with something else, it actually is a new string and is reported is missing (if the stringid is new, too) or outdated (if the stringid is kept).
I do not think this particular case (like the one you reported) happens so frequently. And given the amount of UI and background code changes to support this cross-strings relations, I do not think it happens in any near future.
