delete energy-skate-park directory? about babel HOT 13 CLOSED

I'm not sure, maybe it should be deleted or maybe we should change the file names to energy-skate-park_*.json because when we do port that sim, we'll want these strings?

Maybe we should ask @samreid since he worked on these sims, or @jonathanolson since he originally brought the strings over from the Java.

from babel.

For now I think the directory should go. I would expect that once Energy Skate Park is ported (which could be a long while from now), the strings would be migrated and ESPB would draw them from ESP.

from babel.

I suspect that if there is ever a non-basics version ("Energy Skate Park"), then these strings and most of the JS code will move from energy-skate-park-basics to energy-skate-park, much like the relationship between other "basics" sims (e.g., ph-scale and ph-scale-basics), or sims that are a single screen from some other sim (e.g. beers-law-lab and concentration). What we don't want is a situation like we still have with fluid-pressure-and-flow and under-pressure (see phetsims/fluid-pressure-and-flow#266).

from babel.

@aaronsamuel137 What will be the repercussions of trying to move string files from energy-skate-park-basics to energy-skate-park in the future? Won't that cause problems? What happens if I'm translating the published version of energy-skate-park-basics, and it expects strings to be written to babel/energy-skate-park-basics/, but those strings have been moved to babel/energy-skate-park/ in master?

from babel.

Currently, the energy-skate-park things can be deleted and we must keep the energy-skate-park-basics things. When we create energy-skate-park in the future, we can decide where most strings will live.

from babel.

Removed energy-skate-park strings. Closing.

from babel.

Reopening. I'd like to hear about the question I asked in #6 (comment).

from babel.

I'd have to test this to know for sure, but I think it might work fine.

In phetsims/rosetta#69 I just made so Rosetta uses the same sha as the published sim when looking for the English string files, so even if these change in master, Rosetta will go back to look before the strings were moved.

Babel will continue to have strings for the old version until it is republished.

Again, I'd have to test this to be sure, there might be things I'm not thinking of.

from babel.

I'd have to test this to know for sure, but I think it might work fine.

Are you saying that Rosetta will somehow know that the strings have been moved from energy-skate-park-basics to energy-skate-park in 'master', and will put them in the correct file?

from babel.

Rosetta will put the strings back where it found them. So there will be cases where the strings in babel are different from the strings in ESPB master.

Here's a sequence of events that could happen:

1. ESPB is published with all of the strings in ESPB.
2. Strings are moved to from ESPB master to ESP master.
3. Translator goes to translate ESPB. Because it uses the sha from the published version, it still sees the strings in ESPB, not ESP.
4. Because Rosetta sees the old strings in the published version, those are the keys that are pushed to babel/energy-skate-park-basics. Now master and babel are out of sync.
5. ESPB is republished. Strings are now pulled from ESP master. The next time it is translated, the translations are push to babel/energy-skate-park instead of babel/energy-skate-park-basics since that is where it pulled the strings from. Babel and master are back in sync.

Does that make sense/answer your question?

from babel.

Steps 4 & 5 are what concerns me. Unless someone (a PhET someone) moves all translations from energy-skate-park-basics to energy-skate-park, they will not appear in Rosetta and will need to be retranslated. If there are any near-term plans to port energy-skate-park, then perhaps it would be worth moving the strings sooner rather than later?

I'll label this for discussion at developer meeting.

from babel.

The issue mentioned in #6 (comment) is more general than sim-to-sim dependencies. Anytime that a string is moved from one repo to another, we will need to either (a) lose the translation, or (b) move all of its translations that currently exist, and that are added up to the time that the sim is republished. In the case of (b), this will be difficult to keep track for sims, very difficulty to keep track of for common-code strings.

from babel.

9/17/15 dev meeting
• Try to avoid having this happen
• Move things manually when we have to
• As part of S2105R milestone, identify any strings in sims that should move before the sim is redeployed. (DONE)

from babel.