Paul Mackerras <paulus@xxxxxxxxx> writes:
> Christian Stimming writes:
>
>> Similar to the discussion in git-gui, all user-visible strings are
>> passed through the [mc ...] procedure to have them translated by msgcat.
>>
>> Signed-off-by: Christian Stimming <stimming@xxxxxxx>
>> ---
>> @Paul: Are you interested in applying this? If yes, I'd happily
>
> Yes, it doesn't look too bad. The patch seemed to be line-wrapped and
> whitespace-damaged, though.
>
>> provide the Makefile rules for string extraction and translation
>> catalog updates, but I'd like to hear a proposal or decision on where
>> to place them. Should the po files for translation go into the po/
>> subdirectory? And then a proposal/decision of where to install the
>> compiled .msg catalogs will be necessary.
>
> Yes indeed. Junio?
Before talking about installation location, let me worry a bit
about integration.
This is a bit tricky because of the way gitk.git project was
absorbed in git.git repository. Historically we have assumed
that gitk would always stay a single file project, but with
po/*.{po,msg} and gettext toolchain we would also need a
Makefile target or two for maintaining i18n infrastructure for
gitk.
I think we could do one of three things.
1. In git.git, move the location gitk.git is absorbed one level
down, to gitk/ subdirectory. This can have two variants.
1.a Your gitk.git repository could match this move; from being
a single file project, it would become a single directory,
gitk/, initially with a single file under it
(i.e. gitk/gitk), and then i18n coordinator (Christian?)
and i18n group would provide you with gitk/Makefile and
gitk/po/*.po files. I could just merge the result of such
move without any trick if this happens;
1.b Your gitk.git repository can stay in the current shape of
having a single file gitk in it, with Makefile and po/*.po
files supplied by the i18n group. I would have to merge
such a repository with subtree strategy just like I handle
the absorption of git-gui.git project.
2. Your gitk.git could stay without the actual i18n except the
[mc ...] changes, and po/*.po and gettext toolchain calls
can be directly be in git.git project. In git.git, gitk
would continue to be merged from you at the toplevel.
My preference is 1.b, as the longer term plan (when everybody
has git 1.5.2 or newer) is to eject git-gui.git project from
git.git proper, and use the subproject feature to have
git-gui.git in git.git; it would be good if gitk.git can be
handled the same way, and the layout 1.b would make it the
easiest, as it matches how we treat git-gui.git project now.
About the installation location, I would say we can mimick what
git-gui i18n team does and use $(sharedir)/gitk/lib/msgs to
install the message files.
> Is it possible to include the translations, or at least the more
> common translations, in the Tcl code itself? So far I have managed to
> have gitk be self-contained, in that it doesn't need any external data
> files, which simplifies installation and is a useful attribute in some
> situations.
Anything is possible, but I think that is cumbersome to arrange
and probably wasteful at runtime. You will end up carrying
lines of form:
::msgcat::mcset xx "Origial" "Translation in language xx"
for all languages in the same gitk script. Worse, these mcset
lines are not something translators directly work on; rather,
they are output of msgfmt program.
> Also I would want to be sure that gitk wouldn't crash or fail to
> function if it can't find its message catalogs.
You also expressed in a separate message about "catching package
require msgcat to avoid breakage". I think msgcat package is
part of the standard Tcl distribution since 8.1; how old a
tcl/tk do you support?
In any case, I would very much appreciate if any of these will
*NOT* happen before 1.5.3. git-gui 0.8.0 which is scheduled to
be in 1.5.3 will not have i18n.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
