In some of our localization languages, we have localized terms that should always be in English such as Python keywords and type names. For example:
"annotatedTypeArgMissing"
English: "Expected one type argument and one or more annotations for \"Annotated\""
Spanish: "Se espera un argumento de tipo y una o más anotaciones para \"Anotado\"."
"expectedBoolLiteral"
English: "Expected True or False"
French: "Attendu vrai ou faux"
"exceptionGroupTypeIncorrect"
English: "Exception type in except* cannot derive from BaseGroupException"
Czech: "Typ výjimky v kromě* se nedá odvodit z BaseGroupException."
This came up again today when I filed a bug on the loc team about exceptionGroupTypeIncorrect above. They said that they're willing to fix it, but the right solution is the lock the necessary substring(s) via loc comments. And that's a lot easier than filing bugs. Their bug template is quite annoying.
Assuming that the guy I've been discussing this with in the loc issue above confirms that adding a comment will prompt the loc team to re-localize (or at least review) the associated string, I'm going to try adding comments on a few strings with known issues to see if the process will work for us, or if changes would be needed in our loc build.
Environment data
In some of our localization languages, we have localized terms that should always be in English such as Python keywords and type names. For example:
"annotatedTypeArgMissing"
"expectedBoolLiteral"
"exceptionGroupTypeIncorrect"
This came up again today when I filed a bug on the loc team about
exceptionGroupTypeIncorrectabove. They said that they're willing to fix it, but the right solution is the lock the necessary substring(s) via loc comments. And that's a lot easier than filing bugs. Their bug template is quite annoying.I was under the impression that loc comments weren't supported in
.jsonfiles, but TIL they are: https://ceapex.visualstudio.com/CEINTL/_wiki/wikis/CEINTL.wiki/8696/Inline-commenting-in-source-resource-file?anchor=.json-and-.resjson.Assuming that the guy I've been discussing this with in the loc issue above confirms that adding a comment will prompt the loc team to re-localize (or at least review) the associated string, I'm going to try adding comments on a few strings with known issues to see if the process will work for us, or if changes would be needed in our loc build.