Æ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.
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.
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.
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.
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.
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.
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.
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).
--
\\// Peter - http://www.softwolves.pp.se/
--
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