Open liammulh opened 1 year ago
I dug a bit deeper into this in an effort to determine whether we should update the strings in any way before publishing. The bottom line is that yes, we should, but we should coordinate this with the publication effort, because making the changes to the string files could break existing publications.
Here is some more detail on the situation:
The 1.0 branch of Masses and Springs (MAS) was split from master and subsequently published in August of 2018. Shortly afterwards some changes were made to the strings file on the master branch. Then, in February of 2019, Masses and Springs Basics (MASB) was branched and published in February of 2019. These sims share strings from the masses-and-springs repo, and there were two new string keys added to masses-and-springs-strings_en.json
between these two publications: springConstantPattern
and springStrength
. The latter is fine, since it is only used in MASB. The former, however, is a problem. In MAS, it was just called springConstant
and code added values to it. It now uses springConstantPattern
on master. This means that any locale where MAS was translated and then MASB was not subsequently translated will show this strings incorrectly in the master version. The hu
locale - Hungarian - is an example. Here is what part of the published hu
version of MAS looks like:
Here is the same thing from master:
Also, the string springConstant
is still used in the master version of the code, but it was a pattern in the 1.0 version of MAS and is now a non-pattern. This causes problems with sims that have had MASB translated. An example is German. Here is a part of the German version of MAS on master (Intro screen, unequal spring length option selected):
I can fix this all up, but should only do so when we are on the cusp of publication so that no new translations come in and mess things up.
@kathy-phet and @arouinfar -I spoke with Amy today, and she said that you were thinking that we might have someone other than me branch, build, and drive the QA testing of these sims. That would be great. Then, when the sims have cleared QA but have not yet been published, I could fix up the translations and then they could do the publication. Can we plan on something like that, possibly as part of the next sprint?
Thanks for investigating @jbphet. This seems like a great goal for the next iteration. I updated the entry in the project board form "Recommend for Iteration" to "Highly Recommend for Iteration".
I'm going to remove my assignment until this becomes an identified priority.
Over Slack, @kathy-phet said to me:
There will be higher priority QA tests, but I think at least generating the dev test and putting it into the queue for the back burner QA testing sounds good so if they make it through everything it is there for them.
On it.
The dev test was started, but then delayed due to other priorities. Some publication-blocking issues have been identified:
I'm going to move this from the rosetta repo into masses-and-springs since it is more of a sim-specific problem that affects its translations rather than a general problem with translation utility issue.
Also, in the 7/20/2023 iteration planning meeting it was decided that this republication is not currently a priority for the next several weeks, so I'm going to unassign this. There are a number of issues that came out of a dev test that should be resolved before publishing.
In https://github.com/phetsims/rosetta/issues/393, I wrote:
So this is an issue to track republishing Masses and Springs off of master.