Re: On translation regressions due to dependencies

I have a fairly simple solution -- import shared-mime-info into gnome
CVS and perform translations there, using all the same tools gnome
translators normally use.  It would then be fairly easy to sync
translations upstream periodically, including, at a minimum, at the time
of each gnome release.

This is a good short term solution, is it not?


On Tue, 2004-07-27 at 01:36 +0200, Christian Rose wrote:
> There have unfortunately been significant regressions now in translation
> coverage as we are in the phase of moving over to using
> technologies inside GNOME, like recently with the MIME system, the MIME
> types and their translatable names and descriptions.
> Unfortunately, there's no short-time solution to this in sight as far as
> I can see, and it looks like this will be the case not only in the short
> GNOME 2.8 time frame, but beyond that aswell. The problem is mostly an
> administrative one, and not a minor one mind you, which is why it looks
> difficult to resolve.
> This is basically the problem:
> While some key developers have access to CVS in order to
> be able to maintain their software, many other contributors have not.
> This includes translators.
> Vincent van Adrighem was recently so kind as to research how this
> affected the MIME translations¹. They are easily comparable since many
> of the fd.o shared-mime-info translations are identical or very similar
> to the gnome-mime-data ones.
> The results were devestating. For gnome-mime-data, we have translations
> into 67 languages, many of them 100% complete.
> The current status in is only 13 languages, and most of
> them not even 50% complete.
> As there has been changes in shared-mime-info compared to
> gnome-mime-data, simply copying over the translations unfortunately
> wouldn't solve the completeness problem. The only real solution is for
> translators to have access to fd.o.
> "-- Well, then why don't you apply for accounts?" one might rightfully
> ask. Well, we did, we still do, and it looks like we will still keep on
> doing it. Out of all GNOME translators, I'm currently only aware of one
> (1) GNOME translator who has yet managed to get access to fd.o, and it
> seems he got it by sheer luck.
> "-- Well, that's a start, isn't it?" Possibly, but translation is labour
> intense work, and one could employ a single person full-time day and
> night and he still wouldn't be able to commit all translation updates
> that is done in GNOME cvs on a single day. We have at least 88
> translators who have access to GNOME CVS (and the figure is probably
> still a bit higher, since all translator accounts are not marked as
> such, 120 would be a more reasonable guess IMO). So the problem is a
> quite big administrative one, and it seems currently the administrative
> process isn't even there at fd.o, and noone to the best of my knowledge
> working at resolving it.
> "-- What about the Translation Project then?" Right, in the past we
> suggested fd.o maintainers use the external Translation Project², which
> is a project that allows maintainers and translators to cooperate
> without a common CVS.
> However, as this is done by synching and incorporating pot and po files
> back and forth by mail, which can be very time consuming and also easy
> to forget to do, many fd.o maintainers have been reluctant to use it on
> a frequent basis. This, as in the case of shared-mime-info, leaves
> translators with only a more than half a year old snapshot to work with.
> Suffice to say, much can happen in half a year, and certainly so with
> shared-mime-info. I can very well understand maintainers here -- it's
> not convenient by any means if you compare it to the GNOME process where
> translators work essentially by themselves directly in CVS, and if I
> were a maintainer I would much rather code than having to do the
> synching administrativa required with the TP.
> So where does this bring us? Obviously there are a tremendous amount of
> benefits in the cooperation done at There's no question
> about that, and doing anything else would be silly.
> However, in the long term, we should probably try to consider in advance
> how adopting particular pieces of software, and
> incorporating such dependencies, into GNOME affects other established
> qualities we might have, like current translations and documentation
> etc, in order to not introduce bad regressions.
> In the short term, I think the battle is lost for GNOME 2.8. Even if we
> had 88 fd.o translator CVS accounts ready tomorrow, there's too little
> time left to the GNOME 2.8 release to expect any comparable translation
> coverage like we had before. While some translators work day and night, 
> usually need a lot more time to get some spare time aside to do some
> translation work, so there is often a significant delay in the process. 
> So the sad news is that while we could brag that we had at least 80%
> coverage into 36 languages (and a dozen of thosefully complete) in GNOME
> 2.6, we will probably not end up with more than a dozen 80% complete
> translations in GNOME 2.8, and perhaps not even a single fully complete
> one at that.
> That is, unless we suddenly declare the (very) visible MIME info and
> descriptions not part of the GNOME desktop and not our problem(tm). But
> that would be unfair to users, and still, for all what it's worth, a bad
> regression.
> Christian
> ¹
> ²
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]