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

Re: Summary of Debconf i18n/l10n activities

> I am still puzzled.  Imagine for instance that French translators of
> OpenOffice are willing to use this infrastructure, whereas Dutch
> are not interested.  Will this situation be allowed?

Well, it is quite likely to happen, yes, so my first reaction is to
say that, yes, the system should allow it.

So, to amend what I first answered, the choice of using the
infrastructure will actually be a combination of the wishes by the
upstream and, optionnally, the wishes of the teams (though some
upstream may want to enforce using the system....for instance, for
most Debian translations, we will probably make it non optional for
teams to work with the Debian i18n infrastructure (bazaars are OK, but
some cathedral parts in them allow them to still stand up after a
couple of time).

> > An alternative method could be an "opt-in" system where upstreams are
> > doing a volunteer action to "register" their project (here we come
> > with ideas similar to the TP)
> This is not enough.  For instance Debian maintainers may ask for debconf
> translations (or manpages that they have written), but do not want to
> include upstream PO files.

Yay, sure, my definition was a little bit a shortcut. Of course, when
a given package/software has several trnslatable areas, the system
should offer a method to register only some of them.

> > The push module will of course need to be able to send the
> > translations in whatever format is needed by upstream (PO, XLIFF,
> > Mozilla stuff, whatever...)
> I do not understand how Debian developers will communicate with the
> infrastructure.  Could we pick a random package and define the
> different processes?

Yep. Could be a good idea.

Attachment: signature.asc
Description: Digital signature

Reply to: