From: Junio C Hamano <hidden> Date: 2016-06-15 22:49:25
Ævar Arnfjörð Bjarmason [off-list ref] writes:
Now that Git has the infrastructure for translation in next I'm going
to start submitting patches to make the main porcelain translatable.
This series starts that work, and fixes and also fixes up some of the
infrastructure (like the bug discussed in "Odd encoding issue with
UTF-8 + gettext yields ? on non-ASCII"), and adds tests to make sure
it's all working.
With it applied git-init is the one and only utility of the porcelain
that's translatable. The series includes a translation of it into
Icelandic and Polish.
I think it's ready to be applied. I tested it on Solaris, FreeBSD and
Debian. But there's almost definitely something I'm missing in a
series this big, so it's an RFC.
Thanks; will queue them.
I however strongly suspect that we would be better off first kicking the
earlier parts of i18n topic out of 'next' back to 'pu', as I am hoping
that we can declare feature freeze for 1.7.3 by the end of this week at
the latest, and you can never tell if we got the "infrastructure" right
without playing with a real "user of the infrastructure" like this 17
patch series, which means that the part of i18n topic that is already in
'next' cannot be part of 1.7.3 --- it is way premature.
It was somewhat unfortunate and sad that your "test" series depended on a
few patches from the i18n series, which means it is now taken hostage to
the latter. I'd rather want to have the "test" series in the 1.7.3, and
we need to think about a way to untangle the two topics.
Change the Git build process so that gettext is no longer built by
default as part of Git releases, and include a loud warning to
downstream distributors in INSTALL saying that they shouldn't enable
it.
We're still working out the details of the gettext infrastructure and
currently only a small portion of Git can be translated, so it's
premature to enable it by default.
However it's painful for everyone if the source changes needed for
gettext can't be made in pu without conflicting with other series that
apply to maint/master/next.
When gettext is disabled the whole functionality basically boils down
to this macro definition (or Shell and Perl equivalents) and a few
skipping tests:
#define _(s) (s)
So it's a lot less to get right than if we were enabling it by
default.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
On Mon, Aug 30, 2010 at 21:42, Junio C Hamano [off-list ref] wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
Now that Git has the infrastructure for translation in next I'm going
to start submitting patches to make the main porcelain translatable.
This series starts that work, and fixes and also fixes up some of the
infrastructure (like the bug discussed in "Odd encoding issue with
UTF-8 + gettext yields ? on non-ASCII"), and adds tests to make sure
it's all working.
With it applied git-init is the one and only utility of the porcelain
that's translatable. The series includes a translation of it into
Icelandic and Polish.
I think it's ready to be applied. I tested it on Solaris, FreeBSD and
Debian. But there's almost definitely something I'm missing in a
series this big, so it's an RFC.
Thanks; will queue them.
Thanks!
I however strongly suspect that we would be better off first kicking the
earlier parts of i18n topic out of 'next' back to 'pu', as I am hoping
that we can declare feature freeze for 1.7.3 by the end of this week at
the latest, and you can never tell if we got the "infrastructure" right
without playing with a real "user of the infrastructure" like this 17
patch series, which means that the part of i18n topic that is already in
'next' cannot be part of 1.7.3 --- it is way premature.
I definitely agree that it's premature at this point, if for no other
reason than that I'll never be able to make most of the main-porcelain
translatable by the end of the week.
However, there's another way to do this. Simply disable it by default
in releases. Which this patch implements.
I considered the possibility that we might want to disable it in
select branches when I wrote it, so it's easy to do so. And IMO a
better option due to the reasons cited in the commit message attached
to the PATCH.
It was somewhat unfortunate and sad that your "test" series depended on a
few patches from the i18n series, which means it is now taken hostage to
the latter. I'd rather want to have the "test" series in the 1.7.3, and
we need to think about a way to untangle the two topics.
Yeah I wasn't very careful about keeping the bits already in pu
separate. Untangling them shouldn't be that hard though, but hopefully
with this patch we won't have to go that route.
INSTALL | 17 +++++++++++++++--
Makefile | 4 ++++
configure.ac | 2 +-
3 files changed, 20 insertions(+), 3 deletions(-)
@@ -93,8 +93,21 @@ Issues of note: history graphically, and in git-gui. If you don't want gitk or git-gui, you can use NO_TCLTK.- - A gettext library is used by default for localizing Git. The- primary target is GNU libintl, but the Solaris gettext+ - Git includes EXPERIMENTAL support for localization with gettext+ which is currently disabled by default in official Git+ releases.++ If you really want to build it you have to specify NO_GETTEXT=+ as a Makefile argument. If you're a downstream distributor+ please don't do so without consulting with the Git Mailing List+ first about the stability of this feature.++ It's only being included in releases so that source messages can+ be marked for translation without resulting in painful and+ inevitable merge conflicts between Git's pu branch and the+ rest. END WARNING.++ The primary target is GNU libintl, but the Solaris gettext implementation also works. We need a gettext.h on the system for C code, gettext.sh (or
@@ -272,6 +272,10 @@ ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)ALL_LDFLAGS=$(LDFLAGS)STRIP?=strip+# Disable gettext by default in releases while the implementation is+# settling+NO_GETTEXT=YesPleaseForNow+# Among the variables below, these:# gitexecdir# template_dir
On Mon, Aug 30, 2010 at 21:42, Junio C Hamano [off-list ref] wrote:
Thanks; will queue them.
There's a v2 available here:
http://github.com/avar/git/tree/gettextize-git-mainporcelain-v2
Or: git://github.com/avar/git.git gettextize-git-mainporcelain-v2
It:
* contains the "gettext: Make NO_GETTEXT=YesPlease the default in
releases" patch. Please only apply that to next, not pu.
* A "Makefile: use variables and shorter lines for xgettext" patch,
which implements Jonathan's suggestion of using more variables for
the xgettext invocation.
* Elaborates on the issues facing us in the "gettext.c: work around
us not using setlocale(LC_CTYPE, "")" commit message, and mentions
the perror(3) issue.
I didn't send it to the list because it's a huge series and this is a
little fixup, and I rebased it to inject the Makefile patch early in
the series, which isn't easy to express in a v2 PATCH.
Thanks.
I can also send it to list if you want, but I suspect this is better.
Is that against "next"? For an RFC that's okay, but for a series
that will be part of a release it can be tedious to separate out
(not all topics in "next" necessarily are released, and "next"
traditionally gets rewound after each release).
Comments on the patches:
Makefile: use variables and shorter lines for xgettext
The -o<whatever> passed to cc isn't usually included in CFLAGS,
and a part of me is similarly uncomfortable with including it in
XGETTEXT_OPTIONS. Isn't that parameter something that should be
possible to change in the build system independently from the
user's XGETTEXT_OPTIONS preferences?
gettext.c: work around us not using setlocale(LC_CTYPE, "")
The perror() problem shows up with strerror(), too, of course.
(perror just made for an easier demo.)
gettext: Make NO_GETTEXT=YesPlease the default in releases
Copy-edits for the notes in INSTALL:
+ - Git includes EXPERIMENTAL support for localization with gettext
+ which is currently disabled by default in official Git
+ releases.
s/EXPERIMENTAL/experimental/? No need to shout.
I'd also s/currently // since this will not be current after a while.
+ If you really want to build it you have to specify NO_GETTEXT=
+ as a Makefile argument. If you're a downstream distributor
+ please don't do so without consulting with the Git Mailing List
+ first about the stability of this feature.
Similarly I'd s/really //. If we want to dissuade people from trying
it out, we should probably do that with more explicit statements.
+ It's only being included in releases so that source messages can
+ be marked for translation without resulting in painful and
+ inevitable merge conflicts between Git's pu branch and the
+ rest. END WARNING.
Not sure what this means. Maybe:
The infrastructure is only included in this release to avoid
complications in building other work on top of it. If you turn
it on, expect breakage.
+ The primary target is GNU libintl, but the Solaris gettext
implementation also works.
Is that against "next"? For an RFC that's okay, but for a series
that will be part of a release it can be tedious to separate out
(not all topics in "next" necessarily are released, and "next"
traditionally gets rewound after each release).
Yes it's against next since it had the gettext series merged and next
is about to be released isn't it? I could base it on something else if
that's appropriate.
Comments on the patches:
Makefile: use variables and shorter lines for xgettext
The -o<whatever> passed to cc isn't usually included in CFLAGS,
and a part of me is similarly uncomfortable with including it in
XGETTEXT_OPTIONS. Isn't that parameter something that should be
possible to change in the build system independently from the
user's XGETTEXT_OPTIONS preferences?
Maybe, but it'll always be --output=po/git.pot so I saw no reason to
seperate it. Should it be? The -o for the C compiler changes, but the
"make pot" target will always write to po/git.pot.
gettext.c: work around us not using setlocale(LC_CTYPE, "")
The perror() problem shows up with strerror(), too, of course.
(perror just made for an easier demo.)
Yeah, and everything external like that, unfortunately.
gettext: Make NO_GETTEXT=YesPlease the default in releases
Copy-edits for the notes in INSTALL:
quoted
+ - Git includes EXPERIMENTAL support for localization with gettext
+ which is currently disabled by default in official Git
+ releases.
s/EXPERIMENTAL/experimental/? No need to shout.
OKEY THEN!
I'd also s/currently // since this will not be current after a while.
ok.
quoted
+ If you really want to build it you have to specify NO_GETTEXT=
+ as a Makefile argument. If you're a downstream distributor
+ please don't do so without consulting with the Git Mailing List
+ first about the stability of this feature.
Similarly I'd s/really //. If we want to dissuade people from trying
it out, we should probably do that with more explicit statements.
Thanks.
quoted
+ It's only being included in releases so that source messages can
+ be marked for translation without resulting in painful and
+ inevitable merge conflicts between Git's pu branch and the
+ rest. END WARNING.
Not sure what this means. Maybe:
The infrastructure is only included in this release to avoid
complications in building other work on top of it. If you turn
it on, expect breakage.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:49:25
Ævar Arnfjörð Bjarmason wrote:
Maybe, but it'll always be --output=po/git.pot so I saw no reason to
seperate it. Should it be?
No big deal. I am vaguely worried about interrupted "make"
invocations. Don't gettextized packages typically do something like this?
remove_creation_date() {
sed '#!/bin/sed -f
/^"POT-Creation-Date: .*"$/!b
x
# Test if the hold space is empty.
s/P/P/
ta
# Yes it was empty. First occurrence. Remove the line.
g
d
bb
:a
# The hold space was nonempty. Following occurrences. Do nothing.
x
:b'
}
(cd po && xgettext --default-domain=git ...)
set -e; \
if test -f po/git.pot &&
remove_creation_date <po/git.pot >po/git.1po+ &&
remove_creation_date <po/git.po >po/git.2po+ &&
cmp po/git.1po+ po/git.2po+; \
then \
rm -f po/git.1po+ po/git.2po+ po/git.po; \
else \
rm -f po/git.1po+ po/git.2po+ po/git.pot; \
mv po/git.po po/git.pot; \
fi
The -o for the C compiler changes, but the
"make pot" target will always write to po/git.pot.
In particular, to avoid using a partial .pot file, one might want to write to
po/git.pot+, po/git.po, or similar and then rename it.
On Tue, Aug 31, 2010 at 19:22, Jonathan Nieder [off-list ref] wrote:
Ævar Arnfjörð Bjarmason wrote:
quoted
Maybe, but it'll always be --output=po/git.pot so I saw no reason to
seperate it. Should it be?
No big deal. I am vaguely worried about interrupted "make"
invocations. Don't gettextized packages typically do something like this?
remove_creation_date() {
sed '#!/bin/sed -f
/^"POT-Creation-Date: .*"$/!b
x
# Test if the hold space is empty.
s/P/P/
ta
# Yes it was empty. First occurrence. Remove the line.
g
d
bb
:a
# The hold space was nonempty. Following occurrences. Do nothing.
x
:b'
}
(cd po && xgettext --default-domain=git ...)
set -e; \
if test -f po/git.pot &&
remove_creation_date <po/git.pot >po/git.1po+ &&
remove_creation_date <po/git.po >po/git.2po+ &&
cmp po/git.1po+ po/git.2po+; \
then \
rm -f po/git.1po+ po/git.2po+ po/git.po; \
else \
rm -f po/git.1po+ po/git.2po+ po/git.pot; \
mv po/git.po po/git.pot; \
fi
quoted
The -o for the C compiler changes, but the
"make pot" target will always write to po/git.pot.
In particular, to avoid using a partial .pot file, one might want to write to
po/git.pot+, po/git.po, or similar and then rename it.
I don't know what they usually do. But that looks like a lot of work
to work around a very rare potential edge case. "make pot" is only
ever run manually by a translator right before msgmerge.
In the very rare case where make is interrupted and git.pot is left in
a partial state you'll notice because your msgmerge fails.
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:49:25
Ævar Arnfjörð Bjarmason wrote:
On Tue, Aug 31, 2010 at 19:22, Jonathan Nieder [off-list ref] wrote:
quoted
if test -f po/git.pot &&
remove_creation_date <po/git.pot >po/git.1po+ &&
remove_creation_date <po/git.po >po/git.2po+ &&
cmp po/git.1po+ po/git.2po+; \
then \
rm -f po/git.1po+ po/git.2po+ po/git.po; \
else \
rm -f po/git.1po+ po/git.2po+ po/git.pot; \
mv po/git.po po/git.pot; \
fi
[...]
I don't know what they usually do. But that looks like a lot of work
to work around a very rare potential edge case.
Ah, to work around the interrupted build case is simpler. grepping for
"mv" in Documentation/Makefile would show some examples.
The above incantation is to avoid changing the timestamp on the .pot
file when it does not change.
"make pot" is only
ever run manually by a translator right before msgmerge.
I don't know enough about translation workflows. Don't people
sometimes automatically run msgmerge at build time to get some okay
fuzzy messages when the translation team is off on vacation?