Welcome, Guest. Please login or register.
April 24, 2014, 00:54:17 AM
Home Help Search Calendar Login Register
Show unread posts since last visit.
News: Let Pardus-Anka become #1: Pardus-Anka Bug ReportPardus-Anka World Google+ | The Pardus wiki  | Visit Pardus-Anka official website  | Register as forum member?  Email the moderator!

+  Pardus Worldforum
|-+  Assistance
| |-+  Pardus Project
| | |-+  FAQ Translation
0 Members and 1 Guest are viewing this topic. « previous next »
Pages: [1] Go Down Print
Author Topic: FAQ Translation  (Read 1673 times)
Pardus Guru
Posts: 799

View Profile
« on: January 17, 2010, 17:21:44 PM »

I guess this mailinglist thread is worthwhile sharing (already awaiting final version), especially for those of you who might jump in later.


First of all I must say that We really appreciate the contribution that you're giving Pardus as volunteer translators, you're doing
a great job by giving support to your native languages!

Now I dediced to write down a looong e-mail which could possibly be published as an introductory guide to all translators.

Feel free to ask more questions about the parts that are not clear to you.

When I complete this text with the answers to your additional questions, I'll make the document public.


1. Internationalization (i18n)

Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes.
This is actually what we are doing when we write the software components like Managers, YALI, Kaptan, sysinfo, etc, so this isn't a process that you're directly involved.

In terms of programming, all the strings in an application presented to the user are wrapped with a function call like i18n(), ki18n(), etc. That's all. Say that you're printing a welcome message on the screen in Python:

       print "Hello"

This isn't at all translatable to any language as it doesn't support i18n. But if I import the relevant module and wrap that string by the relevant function like:

       print i18n("Hello")

the text will be replaced by the meaning of "Hello" in the corresponding language when a user runs the application.

When the whole software is internationalized, a translation catalogue (a file with an extension .pot) is generated by browsing all the source code files of that software.
The catalogue is actually a plain text file which keeps the strings to be translated and their corresponding translations in a 2-line format:


       # Some comments about where this string is actually
       # coming from in terms of source code file and line number
       msgid "string to be translated 1"
       msgstr ""

and it goes like this.

2. Localization (l10n)

Localization is the process of adapting internationalized software for a specific region or language by adding locale-specific components and translating text.

Localization is actually what you are doing: Translating the English strings in the translation catalogue to another language.

3. Workflow between i18n and l10n

 - The developer writes its software with i18n support,

 - Once he/she thinks that it's ready for localization, he/she generates a translation catalogue from it, basically a .pot file and makes it publicly available
  to you (through SVN in our case),

 - The translator takes that .pot file and creates a copy of it which he/she calls LANGUAGE.po, e.g.
  If I'm translating the software to Turkish, I take that .pot file and create a copy of it called tr.po.

 - I use vi, nano, mcedit, lokalize, kbabel, or another application to edit that tr.po file for translating the
  strings in it,

 - Once I think that it's enough for that day, I commit it back to where it belongs in the SVN tree.

Some more practical rules and advises are below:

 - You never touch/modify the .pot file once you copy it as your LANGUAGE.po file,

 - If there's already a LANGUAGE.po file then it means that somebody has already started working on it OR the
  developer of the software had created empty LANGUAGE.po files for your convenience.
  All you have to do is to edit it to fix broken or missing translations and commit it back!

4. What happens when I translate and commit the LANGUAGE.po file to SVN?

The developers creates a tarball/archive of their project source codes including the po/ directory which contains
all of the translation work done by you. Once the application becomes a pisi package and you install/upgrade it on your system,
the new translations will immediately be available to you.

If you think that you translated all the strings correctly and committed the LANGUAGE.po file to SVN, you may sit back
and enjoy seeing your translation work on your screen as you use the related software.

5. Oh, I thought I already completed the translation of Kaptan but there are still English messages in it!

Okay, there could be more than one possible cause for this problem. Let's learn about them:

 - You really completed the LANGUAGE.po file and committed it but the maintainer of the project wasn't concerned at all
   to create a new tarball and push that as a pisi update to the repository. So your works aren't reflected at all to
   the package. Just send an e-mail to the pardus-translators list as early as possible OR fire a bug report in bugzilla
   to poke us,

 - You really completed the LANGUAGE.po file and committed it but to the wrong directory under SVN. We'll talk about
   different directory hierarchies in SVN a little bit later so keep reading,

 - You really think you're completed the LANGUAGE.po file but actually there are translations which are marked as fuzzy.
   When a translation is marked as fuzzy, the English string is displayed instead of the fuzzy translation. You have
   to correct that translation and remove the fuzzy mark in the .po file. Let's see an example:

   #, fuzzy
   msgid "Network settings"
   msgstr "A not-really correct phrase about the original string"

   As you can see, that translation is marked as fuzzy and you'll just see "Network settings" instead of the not-really
   correct fuzzy translation. If you're using a graphical tool, re-translating it correctly should be sufficient to mark
   it as non-fuzzy. If you're using a text editor, just remove that ", fuzzy" from the line above, that's all,

 - You really completed the LANGUAGE.po file but the developer has just added a new string and you didn't notice it at all.
   In that case your LANGUAGE.po file will miss the translation for that new string which will cause it to be displayed in
   English. Just open the LANGUAGE.po file, translate the newly added strings and commit it.

6. At the bottom of my LANGUAGE.po file there a lot of translations all starting with #. What am I supposed to do with them?

Nothing! Those are old translations that you've made a while ago but which are not currently used by the application because the
developer decided to not make them appear on the screen.

When the developer updates the POT and PO files (Don't panic we'll talk about that too), the removed strings and their translations
will be moved to the bottom of the PO files and be commented out with # characters so that they are not used at all.

7. I sometimes see that the POT file and all the PO files are modified, what does it mean?

 When a developer adds/removes/modifies some strings in its project source codes, he runs an automated script which reflects that
change to the POT and PO files:

 - If there is/are new string(s), you just have to translate it/them in LANGUAGE.po and commit your changes back,

 - If there is/are removed string(s), its/theirs translation(s) for it/them in the PO file is/are moved to the bottom of the file
  and each commented out with an # character. You don't have to do anything in this case,

 - If there is/are modified string(s), its/theirs translation becomes fuzzy. When you open the LANGUAGE.po file with your favourite
  localization tool or a text editor, you'll see that the relevant translations is/are marked as fuzzy (has a # ,fuzzy line above it).
  You now have to fix its/their translation(s) to unmark it/them as fuzzy.

  Note that you'll see the original English strings instead of fuzzy marked translations when you run an application.

8. How can I understand that there are new additions/modifications to the catalogue files?

First of all you have to follow the pardus-translators and uludag-commits mailing-lists. From time to time, the developers will send
e-mails informing you that you have to update your translations for a given project.

uludag-commits is a mailing-list that only an automated script is allowed to push commit notifications about repository changes. You must
follow that list because if you do so you'll easily notice when someone updates the PO/POT files because he added/removed/modified some
strings from them. A typical commit mail which should poke you is something like that:

 Author: ozan.caglayan
 Date: Thu Jan 14 14:42:38 2010
 New Revision: 27511

 Update messages

 There's one new string to translate

You can easily see that I updated the PO/POT files because I just added a new string to the sysinfo application about swap memory usage.
Now you should update the relevant LANGUAGE.po files to translate that new string and then commit it back to the SVN repository, that's all.

So make sure that you follow uludag-commits list to be able to react as immediately as possible to the translation updates.

9. I'm really confused about the branch/ and trunk/ hierarchy in Pardus SVN repository.
  What are they used for? Where should I commit my translation updates?

You're basically working in uludag repository (http://svn.pardus.org.tr/uludag) which contains the source codes for Pardus technologies.

An SVN project repository is generally divided into three folders:
 - trunk/
 - branches/
 - tags/

"trunk" is the directory under which the main project development occurs,
"branches" is the directory in which you create various named branches of the main development line,
"tags" is a directory of branches that are created, and perhaps destroyed but never changed.

Now let's forget about tags directory and focus over the other ones.

In trunk, there are several directories for several projects like Kaptan, YALI, comar, pisi, kde, etc. This where the main development takes place.
For example, when I found a bug in Kaptan, trunk/kde/kaptan is *generally* the first place where I commit my fix.

If I plan to do radical changes to Kaptan e.g. to add different features to it that will be used in Pardus 2011 but which will not appear
in Pardus 2009, I create a branch in branches/kde/kaptan called for example 2011 and I continue the development in trunk/kde/kaptan and
branches/kde/kaptan/2011 separately.

So, If I add a new string to the 2011 branch of Kaptan and update the POT/PO files, you have to update the relevant PO files in
branches/kde/kaptan/2011/po directory.

Currently we have two main branches for every project: 2009 and Corporate2. Both are active and maintained so you should generally be updating
both branches for every project if you see a translation update in uludag-commits.

If there are no modifications to the strings in a specific branch of Kaptan, and you continue to improve the current translations in trunk/kde/kaptan,
this is the developer's responsibility to take what you changed in trunk/kde/kaptan and apply them over the relevant branches of Kaptan.

10. It is quite possible to see untranslated strings in KDE applications.
   Since KDE isn't maintained in uludag/ repository, where should I update the translations?

Nice question! This is one of the mysteries for translators. From time to time, we add new features to the KDE applications that needs for example a button
in the user interface of that application.

The PO files for KDE applications are either coming from the package itself or from kde-l10n-LANGUAGE packages in the repository.

For example, we recently added a new item in the right-click menu of KMix (The speaker icon in your system tray) which opens pavucontrol for advanced
sound settings. The feature was added to KMix shipped within the kdemultimedia package. As kdemultimedia is a base KDE package, all of its PO files
comes from kde-l10n-LANGUAGE packages.

This is the patch applied to kdemultimedia package which adds that item to KMix:

Index: kdemultimedia-4.3.3/kmix/kmixdockwidget.cpp
--- kdemultimedia-4.3.3.orig/kmix/kmixdockwidget.cpp
+++ kdemultimedia-4.3.3/kmix/kmixdockwidget.cpp
@@ -33,6 +33,8 @@
 #include <kwindowsystem.h>
 #include <kactioncollection.h>
 #include <ktoggleaction.h>
+#include <kprocess.h>
+#include <kmessagebox.h>
 #include <qapplication.h>
 #include <qcursor.h>
 #include <QDesktopWidget>
@@ -98,6 +100,13 @@ void KMixDockWidget::createActions()
    if ( a ) menu->addAction( a );

+  // Add pavucontrol shortcut to the context menu
+  QAction *paction = actionCollection()->addAction( "run_pavucontrol" );
+  paction->setText( i18n ("Advanced Sound Control") );                     <-- A new string wrapped by i18n() -->
+  connect(paction, SIGNAL(triggered(bool) ), SLOT (runPavucontrol() ));
+  QAction *a1 = actionCollection()->action ("run_pavucontrol" );
+  if ( a1 ) menu->addAction( a1 );
  // Put "Select Master Channel" dialog in context menu
  if ( m_mixer != 0 ) {
  QAction *action = actionCollection()->addAction( "select_master" );
@@ -158,6 +167,17 @@ void KMixDockWidget::selectMaster()
    // !! The dialog is modal. Does it delete itself?

+void KMixDockWidget::runPavucontrol()
+    KProcess *pulse_proc = new KProcess();
+    pulse_proc->setProgram("/usr/bin/pavucontrol");
+    if ( pulse_proc->startDetached() == 0 ) {
+        // Error
+        KMessageBox::error(0, i18n("Failed launching pavucontrol, make sure the pavucontrol package is correctly installed."),
+                              i18n("Error launching pavucontrol"));        <-- Two new strings wrapped by i18n() -->
+    }

So when I add this feature to KMix, I also patch the kde-l10n-tr package to add the translations for those 3 new strings. Let's see
this patch:

Index: kde-l10n-tr-4.3.3/messages/kdemultimedia/kmix.po
--- kde-l10n-tr-4.3.3.orig/messages/kdemultimedia/kmix.po
+++ kde-l10n-tr-4.3.3/messages/kdemultimedia/kmix.po
@@ -712,5 +712,14 @@ msgstr "Aygıt Ayarları"
 msgid "Mixer"
 msgstr "Karıştırıcı"

+msgid "Advanced Sound Control"
+msgstr "Gelişmiş Ses Denetimi"
+msgid "Failed launching pavucontrol, make sure the pavucontrol package is correctly installed."
+msgstr "pavucontrol başlatılamadı, pavucontrol paketinin yüklü olduğundan emin olun."
+msgid "Error launching pavucontrol"
+msgstr "pavucontrol başlatılamadı"
 #~ msgid "Current Mixer"
 #~ msgstr "Geçerli Karıştırıcı"

The patch is pretty trivial!

The main problem is that if you don't dig into the paketler-commits list, you won't notice that right-click menu action addition to KMix
until you saw it on your desktop. We're planning an automated notification system for this kind of modifications that'll send an e-mail
to pardus-translators which will tell which package you have to patch and what are the added/modified strings in it.

As you don't have access to pardus/ repositories for now, you can't directly patch packages but if you attach your translation patches in a
bug report that you'll open, we'll apply them as soon as possible to pardus/ repository.

Ozan Caglayan

Pardus-translators mailing list

Former Pardus user, now on OpenSUSE 12.2 (KDE)
Pardus Guru
Posts: 799

View Profile
« Reply #1 on: January 17, 2010, 17:24:22 PM »

> How can I translate the Packagedescribtion shown inside the GUI of PiSi?
> Is there a single PO file available, or must I translate each single
> "translation.xml"?
> Thanks for your effort!
> --Stefan

Hi, I totally forgot to explain about that.

Every package has a translations.xml file which you can translate the package summary & description.

Once upon a time, there were a script which were ran periodically to generate a whole large PO file from
all the translations.xml. Once people updates that PO file, we were updating the translations.xml from that
large PO file. But we didn't use that method for now I don't know why.

We need an easy way to translate package summary & descriptions, I'll think about it.

Former Pardus user, now on OpenSUSE 12.2 (KDE)
Pardus Guru
Posts: 799

View Profile
« Reply #2 on: January 17, 2010, 17:25:02 PM »

> I did a 'svn up', and since some changes were made by the some one else
> too (the developer, some strings were added/changed) it resulted in a
> conflict.
> The first thing I did was to make a 'svn di' of my changes so I could save
> my local, not commited changes. After that I reviewed the conflict and
> there was no direct collision so I decided to merge them. That resulted in
> a po Lokalize could not read, so I deleted the po and made a new 'svn up'.
> Then I just copy and paste from my recently made diff file.
> Could you tell us how to handle this kind of situation in a better way?

First of all to avoid these kind of problems always run "svn up" before starting to work,
and always commit your changes when you're done.

If there's no direct collision after svn up, the conflicted file will be marked with a G:

$ svn up

U po/tr.po
U po/it.po
U po/sv.po
U po/es.po
G po/de.po

something like that. This won't avoid you from committing your local changes.

If there's a real conflict the file will be marked with a C and SVN will ask you what to do
when you ran svn up.:

$ svn up
  U    po/tr.po
  Conflict discovered in 'po/es.po'.
  Select: (p) postpone, (df) diff-full, (e) edit,
          (s) show all options: s
    (p)  postpone    - mark the conflict to be resolved later
    (df) diff-full   - show all changes made to merged file
    (e)  edit        - change merged file in an editor
    (r)  resolved    - accept merged version of file
    (mf) mine-full   - accept my version of entire file (ignore their changes)
    (tf) theirs-full - accept their version of entire file (lose my changes)
    (l)  launch      - launch external tool to resolve conflict
    (s)  show all    - show this list

If you choose postpone, you'll have to resolve the conflict later
diff-full will show the total diff to the file
edit is the one you'll choose to resolve the conflict. It will show both your local changes
and the committed changes to the file separating them with lines like:

<<<<<<<<<<<<<<< merge.right.rXXXXX
>>>>>>>>>>>>>>> working

lines between 'working' marks are the local changes you have on your computer, the merge.right
ones are the committed and conflicted changes. You have to decide which ones to use and merge
them by removing all that >>>>>>>>>> <<<<<<<<<< lines.

Once you cleaned up those lines and fusioned the changes manually with your hand, you can save&exit
from edit mode, and then press 'r' to say that "hey I'm resolved the conflict". Now you'll be able
to commit your fusioned changes back to the repository if you run "svn ci".

mine-full discards all the committed-and-conflicted changes and uses your local version as the new file,
theirs-full discards all your changes and uses the committed version as the new file.

Former Pardus user, now on OpenSUSE 12.2 (KDE)
Pardus Guru
Posts: 799

View Profile
« Reply #3 on: January 17, 2010, 17:27:31 PM »

Antoon Tolboom wrote:
> Thanks for this explanation.

> I agree with Stefan Wilhelm that:
> svn co https://svn.pardus.org.tr/uludag/......./
> svn ci XX.po
> svn add filename
> export SVN_EDITOR=kwrite
> and/or
> SVN_EDITOR="kwrite" svn ci <filename>  (<< I always use this one)
> and the associated specification (f.i. Dutch language update of /trunk/....)
> should be included in the introduction guide/manual.

OK I'll write down an introductory SVN section, too.

> And another chapter is the "Localized Firefox bookmarks" in http://svn.pardus.org.tr/pardus/2009/devel/network/web/firefox/files/pardus/.

Actually this can be explained in KDE/KMix example part.

Former Pardus user, now on OpenSUSE 12.2 (KDE)
Pardus Guru
Posts: 2317

View Profile
« Reply #4 on: January 17, 2010, 21:07:42 PM »

And for a complete overview :
and select January 2010: > [Subject] >[Pardus-translators] Frequently asked questions about translations
Pages: [1] Go Up Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!