From: Christian Stimming <stimming@tuhh.de>
To: Brett Schwarz <brett_schwarz@yahoo.com>
Cc: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>,
"Shawn O. Pearce" <spearce@spearce.org>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
git@vger.kernel.org
Subject: Re: [PATCH] Internationalization of git-gui
Date: Fri, 20 Jul 2007 23:40:27 +0200 [thread overview]
Message-ID: <200707202340.27496.stimming@tuhh.de> (raw)
In-Reply-To: <772058.65660.qm@web38907.mail.mud.yahoo.com>
Am Freitag, 20. Juli 2007 20:34 schrieb Brett Schwarz:
> 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"
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
next prev parent reply other threads:[~2007-07-20 21:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-20 18:34 [PATCH] Internationalization of git-gui Brett Schwarz
2007-07-20 21:40 ` Christian Stimming [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-07-21 16:29 Brett Schwarz
2007-07-20 18:15 Brett Schwarz
2007-07-19 17:33 Brett Schwarz
2007-07-20 5:04 ` Shawn O. Pearce
2007-07-20 8:56 ` Christian Stimming
2007-07-21 2:17 ` Shawn O. Pearce
2007-07-21 7:50 ` Christian Stimming
2007-07-21 8:03 ` Shawn O. Pearce
2007-07-20 9:03 ` Christian Stimming
2007-07-19 10:56 Christian Stimming
2007-07-19 12:25 ` Johannes Schindelin
2007-07-20 4:55 ` Shawn O. Pearce
2007-07-20 17:32 ` Paolo Ciarrocchi
2007-07-20 18:10 ` Junio C Hamano
2007-07-20 18:38 ` Johannes Schindelin
2007-07-20 18:47 ` Paolo Ciarrocchi
2007-07-20 19:06 ` Johannes Schindelin
2007-07-20 19:02 ` Sam Ravnborg
2007-07-20 19:16 ` Xudong Guan
2007-07-21 8:12 ` しらいしななこ
2007-07-21 8:22 ` Junio C Hamano
2007-07-21 13:21 ` Johannes Schindelin
2007-07-21 18:57 ` Paolo Ciarrocchi
2007-07-21 21:25 ` Johannes Schindelin
2007-07-21 22:57 ` Junio C Hamano
2007-07-22 1:12 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200707202340.27496.stimming@tuhh.de \
--to=stimming@tuhh.de \
--cc=Johannes.Schindelin@gmx.de \
--cc=brett_schwarz@yahoo.com \
--cc=git@vger.kernel.org \
--cc=paolo.ciarrocchi@gmail.com \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).