GNOME translation mini-howto attemp

[Peter Tuhársky <tuharsky misbb sk>]

Hi guys,


some time ago I managed to contribute to GNOME translation. The first 
thing I learned has been the lack of documentation.

Maybe the documentation in fact IS somewhere, however not "visible 
enough" and "do this"-like for me, being newbie.


So, I have written something for the newbies. I KNOW it is far from 
perfect, however better than nothing. If there already IS something that 
really covers ALL topics from my howto, then please make it literally 
"at eyes" so that noone could miss it on GTP page.

As of this (my) howto, the most work I feel should be done in order of 
basic tools usage and the very translation from the process point of 
view (go to this page, find Your project, get this file, upgrade by this 
command, submit there).

Please, comment, correct and enhance, and at the end, publish it 
somwhere near the
http://developer.gnome.org/projects/gtp/

so that the newbie will find it easily.


Sincerely
Peter

Title: GNOME translation mini-HOWTO

GNOME translation mini-HOWTO
for the translation newbies



Peter Tuhársky <tuharsky at misbb dot sk>
Last edited: 21.1.2008


If You consider to improve the GNOME translation for Your language, first decide:
1, Do You want just to report some incorrectly translated strings? Then everything You need is GNOME bugzilla account. You fill in the translation bug just like any other bug (that You hopefully report too).
2, Do You want to help translating some apps? Then the following piece of information may be useful for You.
I have written them because I joined the translation recently and I see that such a piece of information would help me, and could help others. Feel free to extend this material and correct the possibly wrong statements. Please, share Your knowledge too.

• Join the gnome-i18n mailing list as that's the place where the majority of the Gnome Translation Project communication happens.
• There is also an additional way of discussion - IRC channel at #i18n on irc.gnome.org
• If You wish to participate on the documentation, GDP has gnome-doc mailing list and GDP IRC channel, #docs at irc.gnome.org.

• Find Your local community by the team or by the language.
• Contact Your team leader. Let him know what You're willing to do. He may offer You some help, guidance and coordination with the tasks that others are working on.
• Waiting for an answer, You can of course move to next steps.
• If the team leader didn't answer, contact some other team member.
• If noone answers in reasonable time (say, two weeks), let the GTP heads know about that.
• If the team for Your language dosen't exist either, start one.

• Explore the terminology, keep translations consistent
• Meet the online resources
• Your translation team probably suggests some online translation dictionary in order to help You with computer-specific terms. Look at these resources and make them familiar to You. You will need them. Don't be shy to consult them.
• Among the general online resources, look at these links: Babelzilla glossary, <put others here>
• You might even join them in order to keep these resources as up-to-date and complete as needed. You do it for Yourself and for newbies too. The higher quality of the resources, the better translations and less work needed to keep them consistent.
• Follow the Microsoft terminology in reasonable way
• Although You may not like the Microsoft, there are good reasons to make the translations consistent with their computing terminology:
• The translations and terminology are usually the best side of their products. This may vary for each country of course, since the translation is held by the the local offices. Some of them possibly have accomplished better job than others.
• They have paid professionals, they have invested resources. The resulting terminology does have it's value, although it is not necessarry perfect.
• You don't waste Your precious time and energy reinventing the wheel.
• It might be "cool" somehow to create different terminology, however at the end it probably dosen't help anyone.
• Be kind to the average users. They probably have learned the computer terminology on Microsoft's products, or will probably have to use them somewhere. Don't make their computer experience harder than necessarry. Don't make them feel hostile. If they are switching to Linux from Windows, there is already much they must learn. Help them. Let them feel comfortably and "home" at least in terms of terminology. Otherwise they could just feel the system "strange" and turn away.
• The professionals do.
• The enterprise market demands the translations to keep the standard PC terminology, that is, like it or not, mostly created by the Microsoft. The enterprise probably has invested to their people in terms of training and personal management. The less hassle, the better chance to adopt opensource technologies.
• If You really hate Microsoft, then remember: You may also fight them with their own weapons ;-)

• Choose Your software
• Although You can do it using any simple text editor that preserves headers and syntax of the file (including Midnight Commander Editor, VI, emacs or others), there also are much more comfortable programs.
• POedit is simple translation tool and quite good start point. It offers all basic functionality needed: authomatic spellchecking, plural editation,translation database etc.
• gtranslator (I personally don't use it, so let the others put here some reasons to use it)
• KBabel is complex and feature rich application. It offers some strong tools: catalogue manager, dictionary generator using previous translations, translation following the source code, and an automathic translation that realy works.
• Regardless of what You use, You will need intltool package.
• First time You use Your chosen software, set Your preferences: The language, name and E-mail address. They will be automatically stored to the files You have edited in order to allow users or translation team members to contact You for bugs, suggestions, job offers and so on ;-)

• The translation process (technically)
• You don't need to be a programmer to translate GNOME packages. All translation is done using PO files.
• Download the latest .tar.bz2 sources file of some package from GNOME ftp or from Translationproject.org.
• Unpack.
• In the po subdirectory, You should find Your language's .po file. That's the point of Your interest.
• If there isn't one, then the application is not translated to Your language. You may either copy the file of the closest language that users in Your country understand, or use the msginit tool with the --locale parameter with value in this form (place the code of Your language instead of xy): xy_XY.UTF-8
• Either way, create the file xy.po (place the code of Your language instead of xy)
• check and possibly edit the header of the file: the language information, country, region, translation team, plural string, and save the edited file back to the po directory. You can borrow these from other .po file of Your language, possibly from other application that already is translated.
• the Project-Id-Version parameter should be in the form project-id version, e.q. gst-plugins-ugly 0.10.6
• run intltool-update xy (place the code of Your language instead of xy) in order to upgrade the file against the most recent english version
• now You can start translating the file in Your editor of choice...
• There are words that should NOT be translated: .desktop, .sound and few others. They are usually labelled by translation note.
• The status of any string can be one of these three: translated, fuzzy and untranslated. The "fuzzy" usually means, that it's been automatically generated by some software and needs human review, or that the previous translator has not been shure about the translation of the string. You can also use this status to mark the strings that You are not sure of.
• The underscore letter "_" used before an alphabetical character means, that the following letter is used as keyboard shortcut. Please choose the letter in such way that there should be no problem accessing the letter from standard keyboard (special national characters are not necessarily good idea here).

• Overall suggestions
• Keep Your priorities. Look at Damned lies page, where the statistics is gathered among GNOME translations. Choose the applications You want to translate, and choose an order of doing that. The amount of work is usually huge, it is necessarry to split it to small pieces.
• Work in steps. Concentrate on finishing one translation before moving to another. Yes, it is sometimes easier to start the work than to finish it. I know it, really! However, the complete translations have greater chance to get accepted, and everytime You send new version of the translation, someone has to review it and so on. So, by sending finished files, You spare the reviewer's time, and give at least something to the community. Otherwise, You could easily end up with bunch of files that You have touched and plan to "finish and send them one day", and guess, that will never happen, or other people will already do the work that time, since they cannot wait for ethernity, nor build on top of Your work (remember, You have sent nothing to date, and they even might not know, that You are working on the same piece of translation).
• So, repeat Yourselve: work in steps. Finish the task, send the file for review ASAP. Only then start the work on other file. If You have accomplished only a partial work, and feel, that You probably will not finish it, send it immediately anyhow, so that others can build on top of Your work. Otherwise You just waste Your precious time, since Your work has not blessed anyone.
• First take care of fuzzy strings. They usually contain considerable amount of nonsense, introduced by machine "approximate" translations, however could be more easily overlooked than untranslated strings, and incorrectly marked as "translated" by the reviewer. At the end, mis-translated or nonsense string causes more harm than correct, yet untranslated (english) one. You might have met such nonsense strings personally, e.q. in error messages.
• There is never "too late" in order to correct the incorrect translations or improve the terminology. Just keep it consistent.
• Community is valuable. There is just too much work for one-man-show. Help the newbies, recognize the talents. One quality team member is probably more important than thousands of translated strings. I mean, that talents are worth the time invested. Sooner or later, Your work for the translation will end, so let someone continue.
• Translation itself is more important than menu shortcuts. Of course the translation should be as good as possible, however if You can't see, where in the menu structure is the string placed, Don't hesitate on the shortcuts: translate the application first. Once You'll have enough time, You can still test the shortcuts in real life, or correct reported bugs in menu shortcuts. Until then, good translation with a possible few shortcut glitches can bless the end users more, than half-translated app with (in fact) no better shortcuts, or even untranslated app.
• Don't underestimate the importance of Your work. The translation enables the software to actually be used by the end users. Whatever great the code behind could be, without clear and smooth tranlation, hardly could anyone use it. Not everyone does handle english so well that he could use the software that is not fully localised. The lack of translation, or its low quality, certainly causes reasonable amount of potential Linux users turn away.