Hi, Duy Nguyen wrote: > On Mon, Jul 23, 2018 at 7:53 PM Brandon Williams <bmwill@xxxxxxxxxx> wrote: >> What criteria is used to determine if something should be translated? [...] > Besides drawing the line "benefit from (not) being translated" varies > from one developer to another. I think it's just easier and more > consistent to stick to "if it's not machine-readable (or really meant > for devs, like BUG()), translate it" and leave it to translators to > decide. Yup, this is my understanding too: everything user-facing (as opposed to machine-facing) that isn't a "this can't happen" local assertion error (BUG) should be translated. Protocol and format errors aren't BUG (assertion error) because they reflect something that shouldn't be possible to happen due to someone *else* behaving badly. BUG is for errors that shouldn't be possible due to the version of Git that produces the message behaving badly. po/README says - Don't mark everything for translation, only strings which will be read by humans (the porcelain interface) should be translated. The output from Git's plumbing utilities will primarily be read by programs and would break scripts under non-C locales if it was translated. Plumbing strings should not be translated, since they're part of Git's API. I kind of wish we had a rule that was less fuzzy, since then we could enforce it. For example, JGit has a rule that *all* strings should be translatable unless they have a comment explaining why they shouldn't be (which goes a little too far --- there are those comments all over the place). Thanks, Jonathan
