Add Swedish translation. - git-version-control

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Add Swedish translation.
Received-SPF: pass (google.com: best guess record for domain of git-ow...@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=xDiubDXIEKR1THsMYvLi9ww3LpMVBM71wvG/lWBCQeOggY5hZzhpg+Yw2K+g7hBoFv
         xalQg6Fyp6GxyVA3TMF3o5wM4h7zh5INTkgp35zHZA+a9l9mTD8yFpNcgJsgY9zEmjdH
         gCuGue/fDHaLAoW1IE8sz+TM3zfOi+jU5W3E0=
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.00.1009131437310.16...@ds9.cixit.se>
References: <20100912202111.B11522FC00@perkele>
	<AANLkTikg1vD33f6Rj4UEzsbrUemta6NbRWWH22h2Y...@mail.gmail.com>
	<alpine.DEB.2.00.1009130810580.31...@ds9.cixit.se>
	<AANLkTinhmBHQzkdEY88Oa-XsZQ4VAUz0Tci+gOt=f...@mail.gmail.com>
	<alpine.DEB.2.00.1009131437310.16...@ds9.cixit.se>
Date: Mon, 13 Sep 2010 15:45:01 +0000
Message-ID: <AANLkTikRGhcHOfR3hioz_oNOs+Yu0nGvGWq22iRws...@mail.gmail.com>
Subject: Re: [PATCH 2/2] Add Swedish translation.
From: =?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= <ava...@gmail.com>
To: Peter Krefting <pe...@softwolves.pp.se>
Cc: g...@vger.kernel.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: git-ow...@vger.kernel.org
Precedence: bulk

On Mon, Sep 13, 2010 at 13:45, Peter Krefting <pe...@softwolves.pp.se> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
