-
Notifications
You must be signed in to change notification settings - Fork 9
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
Address some potential bugs in translations #22
Comments
Potentially, sure. Historically we haven't proactively reviewed and fixed up translations, we've mostly just left this up to the translators and fixed obvious problems if we happened to stumble across them. However, with the Global Initiative up and running, we might consider searching for and fixing problems like those identified above in order to generally improve the quality of our translated offerings. I'd guess this would take a couple of hours to look these over, make the changes, and trigger the rebuilds. And of course there's always a risk that something would come up and it would take longer, or that we accidently undo something that was intended by a translator. It's not my call to make as to whether this is sufficiently important to assign to someone. @zepumph - I'll hand this back to you to see if you roughly agree with my estimate, then I think you should assign to @kathy-phet and @RVieyra to get their input on whether this should be considered for our next sprint. Also tagging @liammulh so that he is aware that this is being discussed. |
Yeah I would love if @RVieyra could chime in a bit about what the global team thinks about taking some time to improve translations like this. To catch up, we have always known there are likely mistakes in translations, but we haven't spent any time fixing them. There are cases where a mistake is obvious enough that we may just want to manually fix it for the translation. For example from phetsims/number-play#226: Likely wanting a closing parenthesis: Closing parenthesis replaced with curly bracket The first comment lists a few ways to find these sorts of problems in the sim translation data. @RVieyra do you think of this as a priority, and something you would like us to spend some time on? |
Two questions (and bringing in @solaolateju , who is more directly involved with hearing out translator issues): (1) Is this parenthesis/curly bracket issue exclusively a matter of punctuation? I want to verify -- is there no issue with the actual translations? (2) How frequent are these issues across PhET's sims? |
Hello! I just saw this again from working on phetsims/build-a-nucleus#76. Sorry about that. Please assign me if you want my input, because I'm really bad at keeping track of things otherwise. @solaolateju met today and were able to discuss this issue and fix a couple of the problems (mostly as an investigation of the more general issue). (1) Yes, the translations are working well, just displaying these punctuation problems. We also discussed having rosetta automatically notice some of the above problems, but most likely it wouldn't be too helpful for parenthesis, as there are as many false positives as bugs. From here, I will go through the last bullet, and bring @solaolateju a list of changes to review, as well as a list of unsure-if-they-are-problems to have him confirm with translators (if applicable). A couple more potential ways to check for problems:
|
I went through and looked at the remaining cases. Most seemed buggy, but I have no idea how all other languages treat parenthesis, so I wouldn't want to just make these changes myself. Over to @solaolateju.
|
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):{{{
}}}
".*\([^)\n]*"
(match an open paren that isn't closed), though we need to be careful about rtl languages here"[^(\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?
The text was updated successfully, but these errors were encountered: