phetsims / babel Goto Github PK

Looks like this was created by @aaronsamuel137. Please describe this branch and its plans for the future.

At developer meeting...

build process is now using babel, so we should move translated strings to babel. @jonathanolson volunteered to write a script to do this (which will be faster and less error prone than assigning it to someone to do manually.)

Slack#developer thread:

@pixelzoom
Why does babel have a “sound-waves-1.0” branch? Aren’t strings always taken from main?
Looks like that branch was created by @matthew-blackman around 9/8/2023.

@matthew-blackman
It looks like that was created in error while cherry-picking updated strings for Sound Waves. Okay if I just remove the branch?

@pixelzoom
I think removing the branch is the right thing to do. But verify with @jbphet.
And you might need to work around branch protection rules to delete the branch.

@matthew-blackman
Thanks! I will reach out to @jbphet for next steps.

It is in somewhat of a gray area. Discovered in phetsims/tasks#875

I am inclined to use this style from Hooke's Law:

  "appliedForceNumber": {
    "value": "Applied Force {0}:"
  },

instead of this style from Hooke's Law:

  "pattern.0value.1units": {
    "value": "{0} {1}"
  },

@pixelzoom @jessegreenberg @jbphet @jonathanolson any thoughts?

Over in phetsims/number-play#226, QA reported some spots that seemed pretty obvious to be a mistake. For example, where a parenthesis is opened but not closed, or there is a third template var curly brace. We spoke to @jbphet and he mentioned that just manually fixing these, if we feel very very confident of translator error, is totally fine.

So we did 98db64e

From that there are a couple of questions more generally (note that by searching in _generated_development_strings you don't search through history, and just current values of strings):

• 2 usages {{{
• 2 usage of }}}
• 86 usages of ".*\([^)\n]*" (match an open paren that isn't closed), though we need to be careful about rtl languages here
• 24 usages of "[^(\n]*\).*" (match a closed paren without an open), again worry about rtl languages and manually inspect things

@jbphet, does this seem like a worth while investigation?

Hi, I've created a fork and I'm checking the 'es' locale. In order to do it properly to make changes acceptable in pull request, I need to know if there is any app to translate and generate the history array entries, or by updating the value property to the right one is enough.

This sim will be for testing translation of these various types of strings that we have.

Examples include:

plain text: "It's not easy being green."

multiline text: eg, "Give me a\nbreak."

HTML text: e.g. "Turning left on red is a bold move."

pattern: eg "{0}: {1}"

For phetsims/build-a-molecule#220

In babel, I see these directories for energy-skate-park and energy-skate-park-basics.

I'm guessing that energy-skate-park/ should be deleted. There is no repo named energy-skate-park, and it contains files named energy-skate-park-basics-strings_*.json.

But just in case... Assigning to @aaronsamuel137 in case there's something else going on here.

[3/8/16, 2:52:40 PM] Chris Malley: Devs: Does anyone object if I delete babel/autoport/ subdirectories for my sims that have been ported to HTML5 and published?
[3/8/16, 2:53:33 PM] Sam Reid: I don’t mind (in fact it is a good idea), but last time I manually committed in Babel there were issues and we were supposed to synchronize with JB next time manually committing on babel.
[3/8/16, 2:53:35 PM] Chris Malley: While I'm at it, I'll do it for all published html5 sims, if no one objects.
[3/8/16, 2:53:39 PM] Sam Reid: +1
[3/8/16, 2:53:53 PM] Chris Malley: If we can get to 2, I'm pushing :)
[3/8/16, 2:55:12 PM] John Blanco: Go for it. I'll pull on Figaro and restart rosetta when you're done just to be safe.

As part of phetsims/chipper#131 I have ported the strings from Java, Flash and Flex to babel in a new directory "autoport". It appears my commit caused failures in rosetta, and many error emails were sent out. @jonathanolson and I looked into it and it seems like rosetta is using the github api for doing git commits, and we aren't sure how it got out of sync, or if all of the commits must be done through the same tooling.

The joist directory of this repo has two files that don't look correct, and are probably there as a result of some of the recent testing. These should be deleted. This was discussed in the 8/25/2015 dev meeting.

After changing a string in a sim and running grunt update, I tried to push the resulting babel change. See phetsims/chipper#1369. But pre-commit hooks are failing in this repo with

$ git commit -m "push to babel after updating strings"
0 errors in 37459ms


[........................................] 100.00%

Error in fulfilling chunk Promise: [Error: Error: Assertion failed: validation failed:
 value should have typeof boolean, value=undefined
 prunedValidator:
 [object Object]
    at window.assertions.assertFunction (http://localhost:63653/assert/js/assert.js:28:13)
    at validate (http://localhost:63653/chipper/dist/js/axon/js/validate.js:23:17)
    at StateSchema.checkStateObjectValid (http://localhost:63653/chipper/dist/js/tandem/js/types/StateSchema.js:154:9)
    at IOType.isStateObjectValid (http://localhost:63653/chipper/dist/js/tandem/js/types/IOType.js:236:43)
    at IOType.validateStateObject (http://localhost:63653/chipper/dist/js/tandem/js/types/IOType.js:273:10)
    at http://localhost:63653/chipper/dist/js/tandem/js/types/StateSchema.js:143:28
    at Array.forEach (<anonymous>)
    at checkLevel (http://localhost:63653/chipper/dist/js/tandem/js/types/StateSchema.js:137:61)
    at StateSchema.checkStateObjectValid (http://localhost:63653/chipper/dist/js/tandem/js/types/StateSchema.js:147:7)
    at IOType.isStateObjectValid (http://localhost:63653/chipper/dist/js/tandem/js/types/IOType.js:236:43)]
C:\Users\Jesse\Documents\Development\phetsims\chipper\js\phet-io\phetioCompareAPIs.js:128
    return !api.hasOwnProperty( 'version' );
                ^

TypeError: Cannot read properties of undefined (reading 'hasOwnProperty')
    at isOldAPIVersion (C:\Users\Jesse\Documents\Development\phetsims\chipper\js\phet-io\phetioCompareAPIs.js:128:17)
    at _phetioCompareAPIs (C:\Users\Jesse\Documents\Development\phetsims\chipper\js\phet-io\phetioCompareAPIs.js:146:10)
    at C:\Users\Jesse\Documents\Development\phetsims\chipper\js\phet-io\phetioCompareAPISets.js:32:28
    at Array.forEach (<anonymous>)
    at module.exports (C:\Users\Jesse\Documents\Development\phetsims\chipper\js\phet-io\phetioCompareAPISets.js:23:9)
    at C:\Users\Jesse\Documents\Development\phetsims\chipper\js\scripts\hook-pre-commit-task.js:168:53
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async C:\Users\Jesse\Documents\Development\phetsims\chipper\js\scripts\hook-pre-commit-task.js:148:25

Node.js v18.12.0

I think @samreid led phetsims/chipper#1369 so assigning to him to start.

In the 1/31/2019 developer meeting, we decided to stop moving over the auto-ported strings from the Java and Flash sims into ported HTML5 sims. The main reason is that the build process has changed, and it will cause translations to be built from auto-ported strings on the first deployment of the sim, which is generally undesirable since there are pretty much always changes to the strings from the Java version, which makes the translation incomplete. This happened when Energy Forms and Changes was first deployed in late January 2019.

The "autoported" directory should be deleted and the step about converting the strings should be removed from the master checklist document.

It's time to clean up babel/autoport/, deleting directories for sims that have been published.

From 2/25/2016 developer meeting notes:

JB: There are _en.json strings in the autoport dir in babel. I accidentally ended up in one of these files when working on the strings for RIAW, though I quickly realized my mistake. These files may be useful for non-ported sims, but useless and potentially a bit confusing for ported sims. Shall we remove them? For that matter, should we remove all autoported strings for translated sims once we’ve decided whether or not to move them over?
• SR: I’d recommend to remove them for sims that have already been created, keep them for sims that have not yet been created. When a new sim is created, we should move the autoport strings over.
• JB: We need to be careful doing this because updates to babel outside of Rosetta may mess up Rosetta. The strings would need to be removed, pushed, then a manual pull on figaro.
• JB: I’ll clean this up for currently published sims, i.e. delete the autoported strings, then do it again some time in the future.

Discovered in phetsims/joist#124

Assigned to @jbphet since he created the babel repo

In issue phetsims/rosetta#329, we note that some translations have "translated" the strings that are within a code pattern. These strings need to remain as original strings, for the code to correctly work. They are basically variable names, not actual text that needs to be translated.

We need to find the translations where the code pattern was mistakenly translated, and fix it. We will do this by hand for the Molecule Polarity strings. Over in phetsims/rosetta#329, we are investigating if babel allows this error to happen now or whether it has a fix already in place.

@oliver-phet - Can you please go through the existing translations, and inspect this row

And if it reads anything differently from the English, replace it with the English version.
{{from}} → {{to}}

And do so without changing the credits?
@zepumph - I think you mentioned you might be able to make a quick script to see which translations needed this hand fix?

Here is a short list CM started:

• da (1)
• fr (1)
• ko (2) -- I think CM means that this impacted 2 such code patterns within Molecule Polarity, so keep an eye out for that!
• vi (1)
• zh_CN (2) -- I think CM means that this impacted 2 such code patterns within Molecule Polarity, so keep an eye out for that!