| Message ID | pull.1088.git.1638514909.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Factorization of messages with similar meaning | expand |
On Fri, Dec 03, 2021 at 07:01:39AM +0000, Jean-Noël Avila via GitGitGadget wrote: > This series is a meager attempt at rationalizing a small fraction of the > internationalized messages. Sorry in advance for the dull task of reviewing > these insipide patches. > > Doing so has some positive effects: > > * non-translatable constant strings are kept out of the way for translators > * messages with identical meaning are built identically > * the total number of messages to translate is decreased. > > I'm inclined to even go a step further and turn these messages into #define > or const strings. This would have the added benefits: > > * make sure that the messages to translate are identical > * create a library of message skeletons to be picked up when new messages > are needed > > What do you think? One slight negative of this approach is that it makes messages a bit harder to grep for. It sometimes really nice to "git jump grep" for specific messages you got to see where they're coming from. I don't think that's a strong objection, though. If this is making the translations overall more maintainable it might be worth the tradeoff. We could also allow GIT_VERBOSE=1 or something to print the file/line of error(), warning(), and die() messages, which solves the same problem. I think Ævar might have had some patches in that direction. -Peff
Am 03.12.21 um 22:55 schrieb Jeff King: > On Fri, Dec 03, 2021 at 07:01:39AM +0000, Jean-Noël Avila via GitGitGadget wrote: > >> This series is a meager attempt at rationalizing a small fraction of the >> internationalized messages. Sorry in advance for the dull task of reviewing >> these insipide patches. >> >> Doing so has some positive effects: >> >> * non-translatable constant strings are kept out of the way for translators >> * messages with identical meaning are built identically >> * the total number of messages to translate is decreased. >> >> I'm inclined to even go a step further and turn these messages into #define >> or const strings. This would have the added benefits: >> >> * make sure that the messages to translate are identical >> * create a library of message skeletons to be picked up when new messages >> are needed >> >> What do you think? > > One slight negative of this approach is that it makes messages a bit > harder to grep for. It sometimes really nice to "git jump grep" for > specific messages you got to see where they're coming from. This can be mitigated by using, for example, git grep -e --stdin --and -e mutually as long as the rewrite keeps the arguments on the same line with the format strings, which it does. Another aspect is that translators lose context. For example, "%s and %s are mutally exclusive" may have to be translated differently depending on what kind of text is substituted for %s. In this example it's probably always command line options (I haven't checked), so not an immediate problem. But something to keep in mind. -- Hannes
Johannes Sixt <j6t@kdbg.org> writes: > Another aspect is that translators lose context. For example, "%s and %s > are mutally exclusive" may have to be translated differently depending > on what kind of text is substituted for %s. In this example it's > probably always command line options (I haven't checked), so not an > immediate problem. But something to keep in mind. Yup. I do not think we are quite ready to have two identical msgid strings to be translated into two different msgstr strings. We've briefly talked about pgettext() a few months ago, but nothing concrete came out of it, as far as I can recall.
On Sunday, 5 December 2021 08:31:38 CET Junio C Hamano wrote: > Johannes Sixt <j6t@kdbg.org> writes: > > > Another aspect is that translators lose context. For example, "%s and %s > > are mutally exclusive" may have to be translated differently depending > > on what kind of text is substituted for %s. In this example it's > > probably always command line options (I haven't checked), so not an > > immediate problem. But something to keep in mind. > > Yup. I do not think we are quite ready to have two identical msgid > strings to be translated into two different msgstr strings. We've > briefly talked about pgettext() a few months ago, but nothing > concrete came out of it, as far as I can recall. > > As a translator, I made sure that all the messages are with the same grammatical structure where the placeholders are only command line options. The same messages with placeholders are meant to convey exactly the same meaning at all their use point. We have all the control on the source code to tailor them so that one message model is only used with specific types of variables (options here). That's another reason why I was proposing to define and name them. If needed, "%s and %s are mutually exclusive" could be turned into "options %s and %s are mutually exclusive" to make it clear that the placeholders can only hold option names.
"Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com> writes: > This series is a meager attempt at rationalizing a small fraction of the > internationalized messages. Sorry in advance for the dull task of reviewing > these insipide patches. > > Doing so has some positive effects: > > * non-translatable constant strings are kept out of the way for translators > * messages with identical meaning are built identically > * the total number of messages to translate is decreased. > > I'm inclined to even go a step further and turn these messages into #define > or const strings. After looking at [01/10] that repeats the same string in many places, I would have to say that we do not want such C preprocessor macros. Having to hunt for an existing message that is close enough to what you want to say, when you are writing a new message, feels a bit too much. I wonder if a tool that - looks for "newly added" messages (by scanning "git diff" output) - compares them with po/git.pot for existing msgid in a fuzzy way to locate the ones that may be candidate for a change like the changes in this series can help developers, though. Thanks.
Am 05.12.21 um 18:25 schrieb Jean-Noël AVILA: > If needed, "%s and %s are mutually exclusive" could be turned into > "options %s and %s are mutually exclusive" to make it clear that the > placeholders can only hold option names. IMO, being less terse helps not only translators, but also users. Regarding this particular message, personally, I am not a fan of "mutually exclusive" (sounds like it's been taken from a law text). How about "options ... are incompatible" or "... cannot be used together"? -- Hannes
Johannes Sixt <j6t@kdbg.org> writes: > Am 05.12.21 um 18:25 schrieb Jean-Noël AVILA: >> If needed, "%s and %s are mutually exclusive" could be turned into >> "options %s and %s are mutually exclusive" to make it clear that the >> placeholders can only hold option names. > > IMO, being less terse helps not only translators, but also users. > > Regarding this particular message, personally, I am not a fan of > "mutually exclusive" (sounds like it's been taken from a law text). How > about "options ... are incompatible" or "... cannot be used together"? Sounds good. Or perhaps "X cannot be used with Y", which may be even shorter and is still clear what it wants to say. X and Y are incompatible. X and Y cannot be used together. X cannot be used with Y.