I noticed there a many new strings to be translated for 2.2 beta (more than 390 new strings for it lang pack with 100% strings translated in 2.1). Here and there I noticed some strings are just obsolete, but they are considered missing, for example "debugstringids_desc,core_admin".
I recall in the past under certain circumstances many strings were considered missing but filled after some days by a AMOS process. Should we expect the same for some of the current missing strings ?
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.
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.
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.