> 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.
signature.asc
Description: Digital signature
