>> [: Chusslove Illich :] >> While intltool does this too, it shouldn't be done. PO processing tools, >> be it PO editors or whatever else, have no obligation to consider and >> parse such comments. > > [: Shaun McCance :] > Are there any processing tools that actually have a problem with this? For one, Gettext tools which have -F option (sort messages by source reference) do not work properly. Oddly, they do not crash or output any warning, only output messages in wrong order. But quite obviously, anything that actually expects to find a file:number there, as stated in Gettext manual, can work properly only by fluke. > [: Chusslove Illich :] > The problem I see with that is that the tag path is no longer tied to the > file that defined it. That's fine when strings only appear once, but how > about this: > > #: C/some-topic.page:42 > #: C/another-topic.page:17 > #. tag-path: title/gui > #. tag-path: td/p > > Which is which? Maybe it doesn't matter that much. I don't know. I'm not a > translator. I'm just trying to make things easier. In this particular case, I cannot see how it would matter which is which. In general, if pairing is important, that is why source references are there in the first place -- to go into the source and check for oneself. (On a side note, if two tag paths with different final element (here .../gui and .../p) have same text in English, it is not unlikely that they may need different translation. This is why I am genereally in favor of Gil's request to put tag paths into msgctxt instead.) > On the other other hand, gettext defines and treats PO files in a way > that's not really nice to third-party tools. I'd love to put some info in > #, comments (e.g. marking a message transliteration-only), but the fact > that it's a controlled vocabulary prevents me. But there is a good reason why #, comments are a controlled vocabulary (so to say). Firstly, processing tools need to know what different flags mean, so it would be bad that each extraction tool can add its own arbitrary flags. An arbitrary flag could later conflict a Gettext flag. Secondly, semantics of flags is they are purely technical, telling something about the structure of the message. Processing tools can use them to validate the syntax or to recognize formatting (e.g. when collecting statistics). > I'd rather not put more and more stuff in #. comments, because it's going > to get in the way of actual comments to translators at some point. A manual author-to-translator #. comment also contains a keyword, TRANSLATORS: by default. Other types of #. comments can follow the same convention. That way any arbitrary property of the message can be set. For example: #. TRANSLATORS: Blah, blah, blah, #. blah, blah, blah, blah, blah. #. TAG-PATH: td/p #. TRANSLITERATE-ONLY (On another side note, I don't think "transliterate-only" deserves such a semi-formal treatment. Normally it should be entirely upon translators whether to transliterate or do whatever else. If the author wants to make that choice instead, that should be explained by an ordinary TRANSLATORS: comment.) -- Chusslove Illich (Часлав Илић)
Attachment:
signature.asc
Description: This is a digitally signed message part.