Ævar Arnfjörð Bjarmason [off-list ref] writes:
On Fri, Aug 6, 2010 at 13:30, Junio C Hamano [off-list ref] wrote:
quoted
That is one good example. Perhaps we can get a list of messages that we
can place in Documentation/ area (e.g. "'Not up-to-date' - this message is
given when you have local changes in a file in the working tree; given by
command X, Y and Z") out of that effort for free? Perhaps such a list can
help us verify that i18n does not break plumbing output (because the list
does not contain plumbing messages)?
We'd get this sort of list out of "TRANSLATORS:" comments for
free. They're automatically extracted and presented to translators and
others with the xgettext program.
Maintaining a list of messages in Documentation/ somewhere that's
bound to get out of date with the source code doesn't make sense given
the TRANSLATORS support.
Read it again---I didn't say "maintaining" a list at all; we are saying
the same thing more or less ;-) You might need to massage the output from
TRANSLATORS: comment to a more readable form suitable for inclusion in the
documentation (depending on how that thing looks like), though.
On Fri, Aug 6, 2010 at 15:48, Junio C Hamano [off-list ref] wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
On Fri, Aug 6, 2010 at 13:30, Junio C Hamano [off-list ref] wrote:
quoted
That is one good example. Perhaps we can get a list of messages that we
can place in Documentation/ area (e.g. "'Not up-to-date' - this message is
given when you have local changes in a file in the working tree; given by
command X, Y and Z") out of that effort for free? Perhaps such a list can
help us verify that i18n does not break plumbing output (because the list
does not contain plumbing messages)?
We'd get this sort of list out of "TRANSLATORS:" comments for
free. They're automatically extracted and presented to translators and
others with the xgettext program.
Maintaining a list of messages in Documentation/ somewhere that's
bound to get out of date with the source code doesn't make sense given
the TRANSLATORS support.
Read it again---I didn't say "maintaining" a list at all; we are saying
the same thing more or less ;-) You might need to massage the output from
TRANSLATORS: comment to a more readable form suitable for inclusion in the
documentation (depending on how that thing looks like), though.
Ah yes. I didn't read it carefully enough. Yeah, if we're just talking
about autogeneration it isn't hard to get a list of all translatable
strings into a single ASCIIDOC page.
I plan to write some translator documentation once this gets in and we
start having people submit translations. E.g. a document that lists
some of the core Git concepts that the translator will need to
translate (e.g. "pull", "push", "commit", "tree", "object" etc.).
On Fri, Aug 6, 2010 at 17:01, Ævar Arnfjörð Bjarmason [off-list ref] wrote:
On Fri, Aug 6, 2010 at 15:48, Junio C Hamano [off-list ref] wrote:
[...]
I don't mean to bombard you with E-Mails, but hopefully this one is a
bit more to the point.
As I'm sure you've gathered by now I'm keen to get this into Git. I'm
also fully prepared to address any specific concerns about the series
before it gets merged.
However, and maybe I'm just dense, I can't really see some unambiguous
things about the series that I could improve from your comments. So
let's try to clear them up, shall we?
My mental plan for this series has basically been as follows:
1. Get it to a state where it can cook in pu [You Are Here]
2. After it's been there for a while get it to master
3. Once it's there for a while and we're sure the new dependency /
code doesn't harm some more obscure systems..
4. Start submitting patches to the main porcelain $(grep
'mainporcelain common' command-list.txt) to make the most common
user-visible messages translatable.
5. Recruit translators to translate the strings in #4. Send
translations in as patches adding/altering the *.po files.
While doing #4 and #5 I planned to write some new
documentation. E.g. a quick guide for Git hackers showing how you can
add strings that are properly i18n-able. And for #5 an equivalent
thing for non-techie translators showing what the need to translate,
how to submit translations etc.
Now, your main concern is that this doesn't break plumbing output. My
plan for that was to just leave it for later. As long as I'm not
altering something in 'mainporcelain common' I'm not going to break
the plumbing.
I think I can read between the lines that you're uneasy about this
approach. But I'm not sure how else to handle it.
One thing that could perhaps help things in the long run would be to
explicitly mark plumbing messages as not for translation. E.g. with a
"commit" -> P_("commit") macro.
That'd also give us something like the Documentation/ page you
suggest, but with only the plumbing messages extracted on a per-tool
basis (using the gettext tools). That'd probably make for a useful API
reference.
To sum it up. I'm happy to amend something in the 5-point plan above,
or to write new code to make the gettext series more acceptable. I
just don't see what that something is.
In any case, thanks for all the work you and others have put into
getting the series into the state it's in today. I really appreciate it.