patchRe: [PATCH] Internationalization of git-gui

After the glossary of terms has been create, it is easy to create the catalog file (assuming we use Tcl's standard mechanism). Each locale should have it's own file, named <locale_name>.msg (for example, es.msg for spanish). Inside that file, you just create entries for each glossary term (the below assumes that the msgcat namespace was imported):

  mcset es Hello Hola
  mcset es "Hello %s" "Hola %s"
    .
    .
    .

You can find more out here if you like http://wiki.tcl.tk/msgcat

HTH,
    --brett

----- Original Message ----
From: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
To: Shawn O. Pearce <spearce@spearce.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>; Christian Stimming <stimming@tuhh.de>; git@vger.kernel.org
Sent: Friday, July 20, 2007 10:32:24 AM
Subject: Re: [PATCH] Internationalization of git-gui

On 7/20/07, Shawn O. Pearce <spearce@spearce.org> wrote:

Hi Shawn, I volunteer to translate all the git-gui messages in Italian.

Just let me if you are interested and please give me an hint on how to produce the translation so that you can incorporate it.

Thanks.

Regards,

Am Freitag, 20. Juli 2007 20:34 schrieb Brett Schwarz:

I beg your pardon, but I think you grossly misunderstood what I meant by "glossary". So before we end up in further confusion, let me clarify how the general translation approach works. I'll use gettext wording because that's what I know (from being the i18n guy in the gnucash project), but you can easily insert any other wording you like here.

#1 For the translation in general, there is the set of all user-visible strings in the source language (here: english). In gettext terms this is called the "PO template file", git-gui.pot, also called the message template file. This set of to-be-translated strings needs to be extracted from the source code, which can be done by the xgettext program.

#2 For each target language, there is a human-readable mapping file that maps each source string (english) into the target language. In gettext terms this is the "PO file", de.po and it.po and ja.po and whatnot, also called the translation file. This is the *only* file translators actually work with. Gettext uses its PO file format here and a plethora of different tools exist to help translators editing these files. (Examples: emacs po-mode, KBabel, ...)

#3 For each target language, the translation files are converted to a (potentially not human-readable) "compiled" mapping file, which is then read at program runtime and used for the actual translation. For the gettext po file format, the msgfmt program can convert this to Tcl's .msg files.

If I understand correctly, your above suggestion implies that for Tcl msgcat, the file in #2 and #3 are one and the same? In my opinion this might make sense if and only if that file format is supported by at least as many translation tools and offers as flexible translation updates as gettext's po file format does. From my experience the po file format indeed offers a bunch of features that other translation file formats are missing but which are of significant help to the translator. That's why I would strongly suggest to do the actual translation inside a po file, and have it converted to the msg file afterwards.

On the other hand when I mentioned a "glossary", I was talking about a simple text file that should collect the 15-20 most important single words from within the project. Those words usually show up in many different translation strings, and as a translator you would easily lose track of which word you translated into which translation. (Example glossary terms: repository, commit [both the verb and the noun, heh], fetch, pull, push.) That's why you would first collect that glossary, then come up with a one-to-one translation for each of the 20 words of the glossary, and *then* use that fixed wording throughout all 200-500 message translations of the actual project.

Christian