On Jan 20, 2005 at 08:31:55PM +0100, Christian Perrier wrote: > The advantage for translators is obviousÂ: the interface is very > simple and involved people can focus on the real workÂ: deal with PO > files, and just forget about "nasty" stuff such as dealing with > various Revision Control Systems or reporting bugs in various bug > tracking systems.
That's my opinion too: especially for proof-readers a web-tool is a must. > On the other hand, other people may have concerns about using an > infrastructure controlled by a commercial company such as > Canonical. The infrastructure itself is, as far as I know, not based > on free software products (I may be wrong...this is not very clear to > me). Rosetta is definitely a closed project. At least for now. That makes it seem a no-go to me. > This is not my own concern, but I feel it may be shared so > I would not drive us into something which could make some people > uncomfortable. Another argument is that the Pootle project seems to > have been adopted (or on its way to be adopted) by several "key" FOSS > projects and has already received a great interest in the i18n/l10n > community. I couldn't login into Pootle to give it a try, but I guess that it's not an official translation platform for these apps, which rather makes is even more difficult to use for efficient work. It's all the matter of adoption of course and it's better than nothing. > I just need your opinion about such ideas....as usually in Debian, the > final decision will need to be made on a consensus basis (or what > will be closer to a consensus..:-))). > We may also just decide to ignore these tools...or build our own (aka > reinvent the wheel)....let's just discuss this. I can't test Pootle just now, but I think it's about as (un)flexible as Rosetta is. As it is GPL, is can surely be developed further to meet our needs. Some ideas for a web-based system: - proper support for the complete gettext specification - database storage - keeping old strings in the database, just in case - keep multiple translations of the same string in the DB, with explanation, why this particular translation is acceptable or not - multiple access levels: Proof-reader, Translator, Coordinator. Only the Coordinators would have the right to "commit" the translations. All the other would go into the discussion queue. - an external API. Useful for package maintainers, who submit their packages' translations to the system. update pot, fetch po etc. from the command line - integration with CVS. Some more ideas needed, how this has to work considering permissions. - string comparison: what has changed inside the string? There is a perl module that does this. - xmlhttprequest-based interface ;) -- Nikolai Prokoschenko [EMAIL PROTECTED] / Jabber: [EMAIL PROTECTED]
