On Mon, Sep 13, 2010 at 13:45, Peter Krefting <peter@xxxxxxxxxxxxxxxx> wrote: > Ævar Arnfjörð Bjarmason: > >> What commands did you use? I different things on GNU gettext 0.18.1 >> using the commands documented in po/README, e.g.: > > I have 0.17, so there may be changes since then. > >> @@ -12,0 +13 @@ msgstr "" >> +"Language: sv\n" > > gtranslator (at least in the version I'm using) kills that line for me. > >> @@ -16 +17 @@ msgstr "" >> -"Plural-Forms: nplurals=2; plural=(n != 1);" >> +"Plural-Forms: nplurals=2; plural=(n != 1);\n" > > another gtranslator oddity (it removes the trailing \n). That one doesn't > matter, though. > >> And the line wrapping is different after a msgmerge: > > I didn't run msgmerge on the output from gtranslator. If I do that, I get > your wrapped version. I see. Emacs's po-mode is maintained as part of gettext.git, so they probably make sure it has the same line wrapping rules, while gtranslator uses something different. >> Having comments before the <msgstr ""> also means it can't be updated with >> the example snippet in po/README. > > Huh? I've never had problems with that in any project I work on. And some of > the editors (notably KBabel) even inserts these comments by itself. I just mean that if we start doing that I'd have to update the naïve munger in po/README's "Initializing a .po file" section. It's not a problem for the format itself. Anyway, we might want to have these to be consistent with the rest of git, which usually adds copyright comments at the top. >> But redundant to `git log sv.po | grep ^Date | head -n1`. > > No. That gives you when the translation was *committed*, not when the string > set it used as a base for translation was created. True, but the PO Date header doesn't tell you what commit the translation is based on, just when the translator did msginit. So it's not very useful either. The best indicator in any case of what needs to be updated is msgmerge on git.git HEAD. >> And since it's autogenerated it'll cause merge conflicts across different >> git branches eventually. > > PO files don't merge properly between branches anyway (one might be able to > set up a custom merge driver that runs msgmerge between the files, but I've > never been able to get that to work), so they are best avoided. Generally, > you only want to update PO files on the mainline version(s), and ignore them > on merge. Yeah, but they'll merge a lot easier if we don't have autogenerated comments in them, and the patch churn will be a lot smaller and more readable. I don't think there's any significant advantage to keeping these comments *in git.git*. At least I can't see a difference when doing msgmerge, or some feature we miss from reading the gettext manual. Of course they're very useful for editing, but that's easily handled by some make target. >> Ditto redundant to `git log sv.po | grep ^Author`. . > > No Language-Team. But, sure. You would have to delete them every time since > any sane PO file editor will add them back automatically on each edit. Hopefully they'll apply my patch so po-mode.el will stop doing that: https://savannah.gnu.org/bugs/?30835 >> Yes they're useful while translating. But as documented in po/README's >> "Updating a .po file" you can use them while doing that without submitting >> them to git.git. > > Sure. But then again you would have to remember to delete them manually. > Everything that requires an extra step of manual commands will make the > hurdle to create translations higher. If we keep these limited header and no comment policies I'll probably just in the future create some script to rewrite the incoming *.po file, drop it in po/util/* and rewrite submitted PO files without bothering translators. >> It's not using the "<subsystem>: <message> <no-full-stop>" >> convention. All the existing commits in ab/i18n use that convention, >> and I'd prefer to keep it that way. > > Well, I don't really care either way. I'll just --amend it :) > Expect an updated version after I go through the review comments I got (I've > also posted the translation to the TP-SV list for review there). Yippie. Looking forward to it. And thanks again for translating Git. The reason I nitpicked your commit was that po/README and interactions with translators are something we're still working out. So maybe we want to completely change how we do it. Threads like these will hopefully help us to arrive at some sane policy. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html