Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Crowdin translations #3274

Merged
merged 1 commit into from
Jul 18, 2024

Conversation

Duncan-Brain
Copy link
Collaborator

New Crowdin pull request with translations

@Duncan-Brain Duncan-Brain requested review from a team as code owners June 25, 2024 22:34
@Duncan-Brain Duncan-Brain requested review from SayakaOno and kathyavini and removed request for a team June 25, 2024 22:34
Copy link
Collaborator

@kathyavini kathyavini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very interesting! This is a nice complement to i18n script because it picks up some things that i18n is supposed to be doing for us but isn't.

Nice changes:

  1. Reordering of keys (not sure why it's happening though given i18n script is being run on all files and that should handle alphabetical ordering)
  2. JSON formatting/spaces (nice)
  3. Picked out at least two strings I noticed that were only partially deleted from app (@Duncan-Brain now what's the best way to make these changes to the English? Can those be directly edited in crowdin as well or is that ill-advised? I'm just thinking we don't want translations of these unnecessary strings from our translators)

Good catches that will be depressingly manual work:

  1. All the mis-formed or accidentally translated keys that delete the translated string 🥲 Surprised that i18n didn't catch and generate the proper keys here though
  2. Parent key being wrong and all child key strings being deleted

BAD changes:

  1. I don't think we can stop escaping spaces in French. Edit: tested, never mind it's completely fine. It's i18n parser that is putting them in, not something that had been done out of necessity
  2. I don't understand the basis for the deletions in common.json, they are legitimate keys, aren't they?
  3. I thought we looked into it and _many is language dependent, English being a language that will never have it. I don't know how to fix it because I believe the result of our last investigation was that i18n generates it according to language and omits it (correctly) for English. Probably an issue others have faced though.

packages/webapp/public/locales/es/common.json Show resolved Hide resolved
@@ -24,14 +24,14 @@
},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The i18n script is failing to reorder the keys alphabetically?

packages/webapp/public/locales/es/translation.json Outdated Show resolved Hide resolved
packages/webapp/public/locales/pt/translation.json Outdated Show resolved Hide resolved
@Duncan-Brain
Copy link
Collaborator Author

Duncan-Brain commented Jun 26, 2024

First ideas are:
Nice:

  1. Does i18n work on the all translations app wide? Or does it work just on touched files? Thats my guess. This could actually get temporarily annoying for alphabetical that i18n should be catching.
  2. Yah! Weird those occurred int he first palce.
  3. Will look into that. My ideal scenario is that when the english source changes: all other languages become untranslated or unapproved.

Good

  1. Yah! I am surprised we didn't notice the crop strings fail.
  2. I will have to check that out -- I am curious. Edit: NICE pesticides.

Bad

  1. Why does french need those? I am not aware.
  2. I think the common.js ones are deleted because they are unapproved -- so once they are approved they will be back. But I am surprised it didn't pull down an empty string. I would have expected the diff to be "MISSING" => "". Edit. It looks like the behaviour is different for a nested string vs a top level string -- will look into fix/workarounds/what is ideal
  3. My thought was we can just add many to English, it will just be a duplicate string like the others are. I thought when I looked that the _many were duplicates of the _other available string but can double check.

@kathyavini kathyavini mentioned this pull request Jun 26, 2024
16 tasks
@github-actions github-actions bot force-pushed the l10n_crowdin_translations_patch/3.6.5 branch 3 times, most recently from cab7057 to f86f79e Compare June 26, 2024 20:41
@Duncan-Brain
Copy link
Collaborator Author

Duncan-Brain commented Jun 26, 2024

@kathyavini Quick updates on the "will look intos"

Nice
3. I think the following flows would work:

  • New strings - added to english by developer for testing seems like good flow
  • Deleted string - deleted by developer seems like good flow - agreed they could get translated but it should not be a huge loss. Maybe having feature branch based translations "sprints" is best.
  • Updated strings - this one is trickier I don't know which is best or will work yet (LF-4029 could be a good test) .
    • The manual Crowdin UI description is: here and I think that would be acceptable, they would just need to let us know to pull a PR for it down
    • The dev initiated update: I believe that the crowdin action has upload argument default of -auto-update (which we could add explicitly) , I am hopeful that this initiates the same default as their: API docs show for updateOption. Would have to test.

Bad
2. This seems to be expected behaviour for json : https://support.crowdin.com/project-settings/#export . I am not sure why but the impact should be low if we expect translations anyways by the time we download.

@github-actions github-actions bot force-pushed the l10n_crowdin_translations_patch/3.6.5 branch from f86f79e to 365d719 Compare July 2, 2024 16:14
@github-actions github-actions bot force-pushed the l10n_crowdin_translations_patch/3.6.5 branch 4 times, most recently from ad30a21 to 66f8fca Compare July 15, 2024 19:27
@github-actions github-actions bot force-pushed the l10n_crowdin_translations_patch/3.6.5 branch from 66f8fca to 2858676 Compare July 17, 2024 22:08
@kathyavini kathyavini merged commit 2a6aacb into patch/3.6.5 Jul 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants