O/H Mike McGrath έγραψε: > Dimitris Glezos wrote: >> O/H Karsten Wade έγραψε: >> >>> For Paul, Dimitris, and others ... >>> >>> Mike and I were discussing CVS structure for cvsl10n. These are >>> configuration choices for e.g. CVSROOT, and etc. >>> >>> Goals: >>> >>> * R/W for the po/ directory in documentation modules (/cvs/docs/.../po) >>> * Same for po/ under any merged packages (< Extras), although for the >>> most part those are projects that should have translation upstream >>> * Pull in sample content from elvis.rh.c:/usr/local/CVS >>> - part of planning to be able to copy all content and switch >>> >>> Here is a *test* import of the existing L10N CVS -- note that this >>> content may get removed at any time, and people in the cvsl10n have >>> write access to it: >>> >>> http://cvs.fedoraproject.org/viewcvs/?root=l10n >>> >> >> Sounds OK to me. What's the next plan? >> >> Some more ideas/food for thought: >> >> We could have "virtual folders" like we do on i18n.r.c: a translator >> does a `cvs >> co translate` there (`cvs co l10n` in our system) and receives >> something like: >> >> anaconda/ >> af.po >> am.po >> anaconda.pot >> ... >> apacheconf/ >> af.po >> ... >> >> Also, our TODO should somewhere include automerge: each time a new POT >> file is >> committed the PO files could be automatically updated (currently not >> supported >> at i18n.r.c but is in the TODO list there too). >> >> Finally, since we're at it, we should probably start making plans for >> http://l10n.fedoraproject.org/. A *great* example is >> http://l10n.gnome.org/. >> This is probably the only tool the L10N community needs (although the >> job can be >> done locally too). Any help from the TurboGears experienced folks in >> Infrastructure would be greatly appreciated. :) >> > You know more about the translations needs then I do. Paul had also > mentioned "http://translate.sourceforge.net/"; as an option. On the one > hand I'd be fine if we wrote our own app in turbogears. On the other > hand, I'd love to use something already out there. Let me see what I > can do about the modules and the po files. See below, after the short explanations. > And just for the education > of myself and those on the list. Can you tell us the difference between > l10n and i18n is, and how you guys do what you do, what the heck a po or > pot file is. Just educate us in general about your needs and how > cvs.fedoraproject.org will help you accomplish them. In short: * i18n: Making something *able* to be localized, ie develop baring in mind that it should be localizable. That might mean, for example, to use gettext to print stuff, not assume everybody uses "am/pm" for time etc. * l10n: Making a product local. Translating strings, make sure encodings work, have proper fonts, keyboard layouts, adopt cultural values, local customs etc. It is the complementary process of i18n: it takes place after it. Basically, the distinction is subtle but we can simply talk about L10N to keep things clear. * POT: A specially-formatted file that contains every string the software has that should be localized (translated). Example: 'anaconda/anaconda.pot'. Example 2: Docs project uses xml2po to grab XML strings and produce POT files. * PO: A one-to-one translation for every string in the POT file. Example: 'anaconda/de.po' holds the german translations of anaconda. A translator initially copies the POT file to 'de.po' and uses tools like kbabel and gtranslator. ## i18n & l10n process * The maintainer creates his product with i18n in mind. She freezes the strings, exports strings in the POT file and tells L10N folks to go on and translate. When the translation freeze comes, he grabs the PO files back and produces localized versions of the application. For software, that means she compiles them into binary MO files and packages the app. For Docs, we just create HTML versions with the translated strings/images in them. * The translators use the POT file to create or update their PO file (using `cp` for the first and `msgmerge` for the second). They then commit the PO file back to the maintainer (either with email or with the project's SCM). Because of the many PO files and their frequent updates, a project usually helps translators by having a web-based statistics page that shows the percentage of translation for each PO file (application, component) for each language. An answer for the question "Why move?" can be found on [1]. [1]: http://fedoraproject.org/wiki/L10N/Projects/CVSInfrastructure#WhyMigrate ## L10N statistics You can see the existing Fedora (Red Hat) translation statistics page at [2] (yes, it should be called l10n-status). The GNOME L10n portal can be found at [3] and the KDE one at [4]. [2]: http://i18n.redhat.com/cgi-bin/i18n-status [3]: http://l10n.gnome.org/ [4]: http://l10n.kde.org/ We want (and need) to create something similar to the above. It is not really urgent though, since translators can see their translation stats locally from their command line. ## The translate toolkit It is basically a set of tools that help managing PO/POT files. It also includes an *online* web-based translation tool (called pootle) that some projects use. Our translators have made it clear they want to use a SCM for the translations and said an *additional* web-based tool would be nice. So, let's first create our SCM and we'll see about whether we should use pootle. It would probably be useful to have pootle installed somewhere (it really helps when we need *fast* translations from *many* contributors). But whether we'll have it by default accessing all files OR leave it up to the language maintainer to choose which PO files will be available through Pootle is another discussion. Hope these helped having a clearer picture. -d -- Dimitris Glezos Jabber ID: glezos@xxxxxxxxxx, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) --
