Re: Transifex instance for GNOME

[Kenneth Nielsen <k nielsen81 gmail com>]

2010/10/15 Johannes Schmid <jhs jsschmid de>:
> Hi!
>
>> I'm absolutely not opposed to such an idea. But I'm also not convinced
>> that we will be able to keep current D-L functionalities. However if we
>> get some new ones, maybe the global balance might still be positive.
>> I think the main objective would be to support (a) auto-commit in GNOME
>> git infrastructure (the blocker is currently on sysadmin side) and (b)
>> auto-commit in an i18n branch of each tracked branch for modules not
>> hosted in GNOME infrastructure.
>
> I personally think that it would simply disburden us from lots of
> development work we had to put into damned-lies. Not that damned-lies is a
> bad system, actually it is pretty good (thanks Claude!) but as we are the
> only ones using it we also have the sole responsibility.
>
>> Here are some steps we could follow to go further:
>> * Find a team of people to take the job
>> * Install a Transifex instance on GNOME infrastructure
>> * Configure Transifex for GNOME needs
>> * Test Transifex global functionality (pilot languages?)
>> * Decide to switch (or not to switch)
>
> I have seen several people working on/with transifex on this list in the
> past. I hope they can give it a go.
>
> We need some kind of timeline though. We need to have everything setup and
> working latest on string-freeze day. And we also need an implememtation of
> our string-freeze-break-detection for transiflex at this point.

WOW easy does it. It sounds a bit like we have already made the
decision. This should be discussed thoroughly before we decide
anything or ask people to do work on it.

While I can certainly support the idea of of-loading work from Claude
and others, we need to carefully consider the functionality, because
right now we have something that works for almost all that we want to
do, and we do not want to go backwards on that account.

Claude writes that while functionality may differ, that it might be ok
as long as the total functionality is high. I only partly agree with
that. I think there is some functionality that is _essential_, and if
that can not be implementer then we should not move.

The functionality that I am talking about is simple though and pertain
to the fact that we work a lot more with sets that with individual
packages. We have to be able to have overviews of sets of modules[1],
(and it would also be nice to have overviews of the overview[2]),
including translations status in the same screen, the same way we have
today. This is so essential to the way we work that we, in my opinion,
cannot do without.

Regards Kenneth

[1] http://l10n.gnome.org/languages/da/gnome-3-0/ui/
[2] http://l10n.gnome.org/teams/da

> Regards,
> Johannes