It is well known that common code strings files on main need to include all keys for all translations in all supported release branches. Unfortunately this is not being done, and it is not being validated. When we delete a key from main, rosetta silently ignores that key, and often deletes any current translations that have been done to that string key (i.e. https://github.com/phetsims/babel/commit/ffb1a5296f0693b709bfb98dd73082ffd237e6d5). From https://github.com/phetsims/babel/issues/24, it is clear to me that our project is too big to continue with our current process of validation (telling people not to do something that is complicated and hard to know when you are doing).
To illustrate the point, I made a script! This script shows how many errors we currently have in release branches. Not great! Adding to dev meeting to try to decide how to proceed. At the very least we need a loud error when something like this happens.
[ ] In addition to this list above, we need to note that strings marked as "deprecated" were brought back over in https://github.com/phetsims/babel/issues/24, and so won't be in this list, but will still want the same solution as what we decide on here. This is the list at the time of this writing:
It is well known that common code strings files on main need to include all keys for all translations in all supported release branches. Unfortunately this is not being done, and it is not being validated. When we delete a key from main, rosetta silently ignores that key, and often deletes any current translations that have been done to that string key (i.e. https://github.com/phetsims/babel/commit/ffb1a5296f0693b709bfb98dd73082ffd237e6d5). From https://github.com/phetsims/babel/issues/24, it is clear to me that our project is too big to continue with our current process of validation (telling people not to do something that is complicated and hard to know when you are doing).
To illustrate the point, I made a script! This script shows how many errors we currently have in release branches. Not great! Adding to dev meeting to try to decide how to proceed. At the very least we need a loud error when something like this happens.