Re: [Doudoulinux-lang] Translation syncing with upstream?
Hi!
Sorry for the extremely late reply Osma. I am afraid we are spread thin
and have been busy. Hope that'll change now!
On Sun, Feb 23, 2014 at 6:13 PM, Osma Suominen <osma.suominen@sange.fi> wrote:
> Hi debian-jr,
>
> Jean-Michel pointed me to the recent discussions here about syncing
> translations between Debian and DDL. I'm a big fan of both Debian and DDL,
> and have been doing a little bit of translation work in DDL in order for my
> kids to have better localized systems. I don't consider myself a DDL
> developer (at least not yet), but I'm interested in helping with the syncing
> of translation work between the two distributions.
A, but you are a developer! :-)
Great that you show interest in syncing translations. I hope that you are still
interested in this!
> I just posted the message below on the doudoulinux-lang list, where I tried
> to understand the current state of affairs in DDL translations. But then I
> thought I'd better also ask for advice here on debian-jr.
>
> I see at least a few challenges in syncing between DDL and Debian:
>
> 1. DDL has its own translation infrastructure, relying heavily on Transifex
> and bypassing the original source packages almost entirely (see my post
> below for thoughts)
>
> 2. There are quite a number of packages and languages in DDL, and each
> package has its own, sometimes peculiar way of managing translations
>
> 3. There is a big version gap in what packages DDL has (currently based on
> squeeze, being updated to wheezy) and what is included in sid or in upstream
> development
Valid thoughts.
> Reading the debian-jr archives, I understood that the preferred way to
> contribute translations back to Debian would be to provide patches against
> the original Debian source packages, sent through the Debian BTS. With luck,
> the Debian maintainers may also send them upstream to the original
> developers. Correct?
Indeed.
> But presumably for those patches to have any effect on Debian or upstream
> development, they should be against current sid/testing packages, not stable
> and definitely not oldstable. So there is a bit of work, which may not be
> fully possibly to automate, to port the translations which have been done
> against old versions of the package, to the latest sid versions (and also in
> the other direction, to benefit from upstream translation work in DDL). Do
> you have any suggestions on how to make this easy?
Sorry no, but the Debian I18n team [0, 1] probably has more knowledge
within this field.
> I also noticed that although DDL has many languages, the coverage of
> translations varies a lot. For example, looking at the mypaint package as an
> example, there appear to be translations for 22 locales in the upstream git
> tree [1] (I didn't check sid sources, but I presume its situation is close
> to upstream). In the DDL Transifex project [2], there are mypaint
> translations for many more languages, including Galician (gl), Dutch (nl)
> and Arabic (ar). But while Galician has 100% coverage, Dutch and Arabic are
> both at only 13%. Presumably the Galician translations would be a good
> contribution to Debian and/or the upstream project, though due to version
> differences the result would probably not be 100% coverage in the newest
> mypaint version. But what about those languages with 13% coverage or even
> less? Does it make sense to contribute such partial translations?
>
> Finally a tool question: What would be an easy way to generate diffs against
> a large number of original Debian source packages? I know I can download
> each of them using e.g. apt-get source and then have two copies of each
> package source, one vanilla and the other modified, and do a diff -ruN
> between the trees.
Maybe you can use debdiff or interdiff from the devscripts package maybe?
> But it would be much more convenient to have something like a svn or git
> checkout of the original Debian sources. I could then do my local
> translation updates on top of the original and finally generate the patches
> simply using svn diff or git diff. When a new version is available from
> Debian, I'd like to do a git pull or svn update which preserves my local
> changes, instead of redownloading and manually merging my own changes. Is
> this possible with current Debian package tools?
Are you looking for something like debcheckout (also in the devscripts package)?
It will checkout the sources from version control, if the package's
control file lists
a Vcs-Url, as many (most?) packages do.
[0] http://i18n.debian.org/
[1] https://wiki.debian.org/Teams/I18n
Best,
Per
> Thanks,
>
> Osma
>
> [1]
> https://gitorious.org/mypaint/mypaint/source/e44327704a3a9284e9eeecec5812d072bb3c4a15:po/
>
> [2] https://www.transifex.com/projects/p/doudoulinux/resource/mypaint/
>
>
>
> On Sun, 23 Feb 2014, Osma Suominen wrote:
>
>> Hi Jean-Michel!
>>
>> Picking up where we left...
>>
>> On Mon, 6 Jan 2014, Jean-Michel Philippe wrote:
>>
>>> It seems people are more encline to start improving translations
>>> applications for DoudouLinux than for upstream projects directly. This
>>> is quite logical since they clearly see the benefit: their children!
>>> Also the problem with upstream projects is that they're using
>>> independent repositories and processes. Transifex solves this by
>>> providing a unique user account and a single access point.
>>>
>>> Ideally, if all the projects were sharing the same translation
>>> infrastructure, Transifex or another one, life could be easier for
>>> everyone. The only missing feature in Transifex is the ability to share
>>> a resource between projects, which would allow us to just symlink to
>>> upstream translation projects instead of duplicating their messages.
>>
>>
>> Yes, I think something like Transifex would be very good to share between
>> upstream and DDL. But as you say Transifex is not a shared resource, so
>> although some upstream projects may use it, they have their own Transifex
>> project and there is no automatic syncinc. Which is too bad, because it
>> would be very convenient for sharing translations...
>>
>>> Take a look at lang/trunk/ on SVN. The script fetch-pofiles is supposed
>>> to fetch and merge PO files from upstream, provided you give the URL in
>>> a per-resource configuration file. I remember to have found it not so
>>> satisfying, I don't remember exactly why. Maybe the merging operation
>>> was more tricky than imagined.
>>
>>
>> I took a deeper look at the scripts. I think I now roughly understand how
>> things work with DoudouLinux translations.
>>
>> The problem I see w.r.t. merging with Debian is that the DDL translations
>> are all bundled into a separate package, which then overrides message files
>> and other language-specific resources in the original Debian packages. For
>> example, the message file /usr/share/locale/fi/LC_MESSAGES/gcompris.mo is,
>> according to dpkg -S, originally present in gcompris-data, but overridden by
>> doudoulinux-l10n-fi-updates. There is thus no real integration with the
>> original deb package (gcompris-data in this case), so it is not entirely
>> trivial to create a patch against the original Debian source package.
>>
>> I think I can understand why you have set up things this way, as it
>> probably makes translations much easier to manage than having to manipulate
>> the language files in each Debian source package separately and then
>> recompiling the full packages.
>>
>> Now if we take the creation of patches against original Debian source
>> packages as a goal (as suggested recently on the debian-jr mailing list), I
>> think it can be achieved in two different ways:
>>
>> 1. Switch to a process where translations are maintained by modifying the
>> original source packages, which are then recompiled for DDL. Creating
>> patches for upstream Debian packages would then be trivial.
>>
>> 2. Keep the current model of doudoulinux-l10n-* packages, but write tools
>> that merge the DDL specific language files (.po etc) back into the Debian
>> packages so that patches can still be generated.
>>
>> I think neither way is easy, but 1. might be entirely unrealistic?
>>
>> There's also the problem of differing software versions in DDL / Debian
>> sid / upstream, which may create interesting merging issues, but I haven't
>> thought of that in detail. Also I have not looked closely at the merging
>> capabilities of Transifex, except that some details of the merging process
>> seem problematic from the point of view of having different versions of the
>> original software. If you push translations for an older software version
>> than what is currently in Transifex, some messages may be lost if you're not
>> careful. At least that's how I read the description of the --source argument
>> of transifex-client:
>> http://support.transifex.com/customer/portal/articles/996211-pushing-new-translations
>>
>> What do you think?
>>
>> -Osma
>>
>> --
>> *** Osma Suominen / Osuuskunta Sange *** osma.suominen@sange.fi ***
>> *** PL 197, 00131 Helsinki *** 040 - 5255 882 ***
>>
>> _______________________________________________
>> Doudoulinux-lang mailing list
>> Doudoulinux-lang@gna.org
>> https://mail.gna.org/listinfo/doudoulinux-lang
>>
>
> --
> *** Osma Suominen / Osuuskunta Sange *** osma.suominen@sange.fi ***
> *** PL 197, 00131 Helsinki *** 040 - 5255 882 ***
>
>
> --
> To UNSUBSCRIBE, email to debian-jr-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> Archive:
> http://lists.debian.org/alpine.DEB.2.02.1402231842150.2620@aulis.sange.fi
>
Reply to: