publishing maintenance release of sim makes previous translations unavailable

[jbphet]

I published a maintenance release of Friction to add QA credits a few days ago. I just checked the translations, and several are not available. For instance, if I attempt to access the Danish translation, I see this:

If I change the URL to point to https://phet.colorado.edu/sims/html/friction/1.2.0/friction_da.html instead, the sim is found. So, it looks like translations are not being regenerated when a maintenance release is made.

[jbphet]

Assigning to myself, since I will be taking over maintenance of Rosetta, and I will work with @aaronsamuel137 to resolve.

[pixelzoom]

Can someone summarize what's causing the problem?

[aaronsamuel137]

The problem is that grunt deploy-production by default causes build-server to build locales=en. Therefore, when a new version is deployed, "latest" is changed to point to the new version directory, which only has an english translation in it.

However, we don't want to build locales=* because that will build everything that has strings in babel. We want it to build everything that has been translated already, which is what @jbphet and I implemented.

We've changed the default of grunt deploy-production to have this behavior, however maintenance releases of sims that don't have the latest chipper will need to use grunt deploy-production --locales=*, as a way of telling the build-server to republish all translations that have already been published.

This may not be the best solution, but it's the best we could think of to avoid sims having to patch the latest chipper. One of the main confusing points is that grunt locales=* builds everything that has strings in babel, whereas grunt deploy-production --locales=* builds only what has already been translated on the website.

[pixelzoom]

@aaronsamuel137 wrote:

One of the main confusing points is that grunt locales=* builds everything that has strings in babel, whereas grunt deploy-production --locales=* builds only what has already been translated on the website.

Recommendations:
(1) Don't use locales=* for this situation in deploy-production, choose a different option.
(2) Document the option in grunt --help.

[samreid]

@aaronsamuel137 said the new way to deploy to the production server is just "grunt deploy-production", it will automatically do all of the correct locales.

@jbphet suggested patching old sims so they don't have different locales=* behavior, which was required by older versions of chipper.

@pixelzoom said it would be a lot of work to update last 10 deployed sims to use latest chipper.

@samreid asked: does grunt deploy-production just invoke the build server? The answer is yes, but it uses the local shas on your machine. So you build it once on your machine with grunt, then grunt deploy-production so it gets the right shas.

@pixelzoom asked: why does grunt deploy-production need to know what locales to build? Can't it just build the appropriate locales? Or if no options provided, then build all of the locales on the site?

@aaronsamuel137 said: the old behavior is just passing _en, so we could make a hack that makes it so _en builds all locales. But @jbphet and @aaronsamuel137 agreed that was too confusion, even though it would have the correct behavior. The locales=* would work perfectly for previous sims. Ultimately we could get rid of locales=* after all sims are "recent enough".

@pixelzoom was wondering if you would ever want to just build a specific subset of locales?

@jbphet not aware of a case where that is true. Cannot do that anymore, deploy-production means to deploy everything

@jbphet points out that maintenance releases are rare, therefore it may not be worth the effort to retrofit old sims. Just use --locales=* and that should fix it.

Consensus
@pixelzoom says what about making it so that if you do not provide locales, it infers locales=. Then the semantics of --locales= wouldn't be so confusing.

@pixelzoom reaffirms that we must document the --locales option in grunt deploy-production, we should document that sims before $CERTAIN_DATE (yesterday Nov 9, 2015) must use that option. Once all sims are more recent that $CERTAIN_DATE, we can remove this option.

[aaronsamuel137]

I've made this change. Want to review @jbphet?

[jbphet]

Reviewed. Other issues have come up related to this, such as phetsims/perennial#8, but we have a workable solution. Closing.