Translation process

Development
21

Good question. I still need to document this, so let me try to start here. Note that, so long as you’re not messing with adding/removing format strings, What I write should work (and automatically flag existing translations as out-of-date). I want to ensure my stuff is correct, so I will make a change and validate everything as I write … may take a bit of time to be done, but in process!

[[Edit: Realized I wrote the necessary support for handling mismatched format specifiers also … so should “just work”]]

2 Likes
22

No rush - I’m still working on my local branch and can verify the text as English. I just won’t worry about running the python script or updating the other languages yet.

Actually… The other languages are NULL right now; there are not translations yet. It’s just a matter of the correct way to get the history/json back in sync with en-us.h without borking everything :slight_smile:

2 Likes
23

What I’m about to try (in a nutshell):

  1. Change src/translation/en-us.h to modify the new string (or add a string)
  2. run python3 ./src/translation/json2h.py to regenerate headers
  3. Note the error message that things have changed… but also that this generates a new file in ./src/translation/history/…
  4. cp ./src/translation/history/new__en-us.json ./src/translation/history/en-us.json
  5. run python3 ./src/translation/json2h.py to regenerate headers

That’s all that should be needed. Will test/post results … note that a clean build is recommended:

  1. Build as listed in ./readme.md:
    • cmake -S . -B build_rp2040 -DPICO_SDK_FETCH_FROM_GIT=TRUE
    • cmake -S . -B build_rp2350 -DPICO_SDK_FETCH_FROM_GIT=TRUE -DBP_PICO_PLATFORM=rp2350
    • cmake --build ./build_rp2040 --parallel --target clean
    • cmake --build ./build_rp2350 --parallel --target all
    • cmake --build ./build_rp2040 --parallel --target all
    • cmake --build ./build_rp2350 --parallel --target all
1 Like
24

OK, some thoughts on why I had it error out and require manually copying the new file…

Having the script error out initially forces manual review and commit of the changed en-us string. This helps prevent github actions from “accidentally” approving changing existing strings.

Maybe this can be further loosened (e.g., go fully automatic), but I didn’t want to start with that.

2 Likes
25

Ok, and I was able to confirm the following behavior:

  • adding a new string to en-us.h – works as above
  • modifying a string, but same format specifiers
    • existing translation are still used
    • existing translations are marked as outdated
  • modifying a string, changing count of format specifiers
    • existing translations are NOT used – reverts to en-us
    • existing translations are marked as outdated
1 Like
26

I think that is exactly the desired operation (IMO). That makes the most sense.

As I said, I didn’t dig too deep into how it all works; I didn’t need a new distraction (haha). I just didn’t want to make an unnecessary mess with a later PR.

I did the ran the script, copied new to existing in ./history and ran it again. It all looks good. I did a make clean in the build src directory to force a full rebuild. (Ope, another case of me not reading the docs… I’m just used to doing a make clean if the Makefile already exists. I’m only building for the one target I have)

2 Likes
27

OK, I couldn’t help it. I wanted to see if the new JSON format was usable from a webpage to enable editing.

I created a translation editor branch, with corresponding Issue #194 tracking all the features I want the editor to have.

Currently, it just loads the JSON, with a few minimal checks for detecting if the strings are outdated.

NOTE: All strings are outdated because there is no record of which EN_US string they were originally translated from. Once the “Save” option is written, existing strings should be very easy to review, with updating being as simple as undoing the checkbox that flagged them as old.

test by: python -m http.server 8000, then loading https://localhost:8000/editor/translation_editor.html

2 Likes
28

Well, the branch seems to be working now (as of commit “And allow exporting the new translation also” aka 1cf2c24.

  • The UI isn’t pretty.
  • It doesn’t explain what the checkboxes mean (translated string, if any, was not based on most recent en_us string).
  • resulting JSON is dumped only to console (hit F12 in edge to view)

That said, it appears functional.

((Wheee…! I remembered why I hate Javascript through this process))

Documentation for use:

  1. sync the branch with the editor
  2. from root of depot:
    pushd ./src/translation && python -m http.server 8000 && pop
  3. then, in Edge, load http://localhost:8000/editor/translation_editor.html
  4. Review an existing translation … e.g., PL-PL, by switching to its tab
  5. Note that the strings are all marked as “old” (checkbox is checked) … this means it’s not known yet which en-us string was used for the translated string. In this case, the translator should review the translated string vs. the next column, which shows the current EN-US string used for that text ID.
  6. Make some edits to existing strings, or un-check the checkbox to indicate an existing string is accurate.
  7. Click the Copy to clipboard button
  8. Paste over the existing file in ./src/translation/templates/

Example:

  1. Look at PL-PL tab.
  2. Find the translated string for T_MODE_MODE
  3. (Presume it’s a correct translation for the current string EN-US string, mode … since this is just example.)
  4. Because it’s accurate for the current EN-US string, un-check the checkbox.
  5. Now, click on the Copy to clipboard button
  6. Open ./src/translation/templates/pl-pl.json
  7. Ctrl-A (select all), Ctrl-V (Paste)
  8. Review the differences, using git diff or your favorite IDE.

If all went according to plan, the only difference should be that the pl-pl.json now lists mode as the source en-us string for that ID, showing the same translation as before.

It’s good enough that I’m going to merge it. There’s almost no risk, as it’s entirely new files. And, it’s actually functional. :tada:

NOTE: There are likely bugs. I’m not well versed in coding for today’s web pages. File issues if you find them.

EDIT: updated to reflect copy-to-clipboard functionality.

1 Like
29

Note: Still plenty of things need doing…

  • Update CMakefiles.txt to ensure translation headers are generated when required
  • Update github action to fail if format specifiers differ between translations (already written in the script … just need to expose the error / test the action
  • Pull language data from github (instead of local files)
  • etc.
1 Like
30

Wow! Some major updates to translation coming in! You must be feeling motivated, thank you so much for handling this.

2 Likes
31

We’ll know that ultimate geekdom is obtained when there is a Klingon version of the BusPirate. :smile:

3 Likes