Thanks for your helpful comments earlier. I have now done much of the work to do message translation for the dgit package. The results are now in experimental, and can be found here: https://browse.dgit.debian.org/dgit.git/tree/?h=debian/7.0_pre1 or with `dgit clone dgit experimental'.
I'm still working on marking up git-debrebase for message translation, and haven't done anything about the docs. When I have done those things, and subject to any review comments I get here, I intend to call it 7.0 and upload to sid. Comments welcome, particularly on the file po/README. https://browse.dgit.debian.org/dgit.git/tree/po/README?h=debian/7.0_pre1 I am considering creating a salsa repo for translation merge requests, by analogy with what was done for debian-policy: https://salsa.debian.org/dbnpolicy/policy-l10n-merge-requests-here If I do create such a repo, I will probably rebase PR branches onto my own master, rather than using `git merge', because I prefer to make the history more linear-looking. Would that be a problem ? It occurs to me that maybe this kind of thing should be in a translation teams salsa project, and a standard naming convention, etc. I even wonder whether it would be sensible to make some kind of automatic dgit-based mirroring setup so that translators can work in a uniform way, with git, on any package. Of course a translator can just use `dgit clone' right now, and `git-send-email' or something to file their results in the Debian BTS, but that doesn't give a pretty web ui. One difficulty is that I am very much in the habit of constructing my error messages out of pieces. This is recommended against in the gettext manual, and I understand the reasons. However, the prescription to make each message be a whole sentence is impractical from an implementation point of view: Both because it's impractical to write the source code that way (since in neither the places where the message fragments are generated, and where they are consumed, have is there enough information to be able write down that whole sentence); and because it would result in many cases in a combinatorial explosion of different message strings (sometimes with different combinations of %-substitutions etc.) I hope that in languages where inflection and agreement are important, translators will be willing to fudge this, and that users of my programs (the latter being - at least sort-of - programmers) will be able to cope with the resulting odd-sounding messages. I guess these kind of problems are hardly new. Regards, Ian. -- Ian Jackson <[email protected]> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
