date: Note for translators not included in .po files
Subsystems (2)
A note for translators in date.c is not included in git.pot. Namely, the following note from date.c:147 is not included
(https://github.com/git/git/blob/v1.9.2/date.c#L147):
/* TRANSLATORS: "%s" is "<n> years" */
This is a very useful note for translators (in fact, I think the zh_CN translation for date.c:149 might be a little off because this note was not included. My Mandarin is rusty, but I believe "<n> years, <m> months ago" should be expressed without a comma).
According to po/README, the l10n coordinator is responsible for updating the git.pot file. Would it be possible to update it based on v1.9.2 and include the above comment?
By the way, I am trying to organize contributors to produce a Japanese localization for Core Git. Currently we have plenty of interest but only two contributors. If you or anyone you know would like to contribute please visit the repository here: https://github.com/modocache/git-po-ja
Thanks!
- Brian Gesiak
2014-04-17 6:51 GMT+08:00 Brian Gesiak <[email protected]>:
Quoted 6 lines
A note for translators in
date.cis not included in git.pot. Namely, the following note from date.c:147 is not included
(https://github.com/git/git/blob/v1.9.2/date.c#L147):/* TRANSLATORS: "%s" is "<n> years" */
Comments for translators will be extracted to pot file automatically, when run xgettext with "--add-comments" option.
-c, --add-comments
place all comment blocks preceding keyword lines in output file
For example, the comments in the following code blocks will be extracted.
/* TRANSLATORS: "will be extracted." */
strbuf_addf(&sb, Q_("%lu year", "%lu years", years), years);
strbuf_addf(&sb,
/* TRANSLATORS: "will be extracted." */
Q_("%lu year", "%lu years", years), years);But if the comment is not right before the l10n markers, such comments will not be extracted. E.g.
/* TRANSLATORS: "WARNING: will NOT be extracted." */
strbuf_addf(&sb,
Q_("%lu year", "%lu years", years), years);
/* TRANSLATORS: "WARNING: will NOT be extracted." */
strbuf_addf(&sb, Q_(
"%lu year", "%lu years", years), years);I will scan all the codes and make a fix.
Quoted 10 lines
This is a very useful note for translators (in fact, I think the
zh_CNtranslation for date.c:149 might be a little off because this note was not included. My Mandarin is rusty, but I believe "<n> years, <m> months ago" should be expressed without a comma).According to po/README, the l10n coordinator is responsible for updating the git.pot file. Would it be possible to update it based on v1.9.2 and include the above comment?
I could generate a new git.pot for "maint" branch, but fixes for codes may only contribute to "master" branch.
Signature · 1 line
Jiang Xin
2014-04-17 6:51 GMT+08:00 Brian Gesiak <[email protected]>:
Quoted 4 lines
According to po/README, the l10n coordinator is responsible for updating the git.pot file. Would it be possible to update it based on v1.9.2 and include the above comment?
I have pushed a polished "git.pot" to the maint branch of git-l10n/git-po. It's based on Git v1.9.2, and you can get it from:
https://github.com/git-l10n/git-po/blob/maint/po/git.pot
But if you want to translate for the upcoming Git v2.0.0, you can use "git.pot" in the "pu" branch as a template. See:
https://github.com/git-l10n/git-po/blob/pu/po/git.pot
Quoted 12 lines
By the way, I am trying to organize contributors to produce a Japanese localization for Core Git. Currently we have plenty of interest but only two contributors. If you or anyone you know would like to contribute please visit the repository here: https://github.com/modocache/git-po-ja
Thanks!
- Brian Gesiak
--
To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 8 lines
蒋鑫 北京群英汇信息技术有限公司 邮件: [email protected] 网址: http://www.ossxp.com/ 博客: http://www.worldhello.net/ 微博: http://weibo.com/gotgit/ 电话: 18601196889
cover extract proper comments for l10n translators
In reply to Brian GesiakWhen generate git.pot, many irrelevant comments are extracted as references for translators, but one useful comment is lost. This series patches will fix this issue.
Jiang Xin (3):
i18n: Fixes uncatchable comments for translators
i18n: Only extract comments marked by special tag
i18n: Remove obsolete comments for translators
Makefile | 2 +- builtin/init-db.c | 8 +++----- date.c | 2 +- diff.c | 8 -------- 4 files changed, 5 insertions(+), 15 deletions(-)
Signature · 1 line
1.9.2.461.g942803f
PATCH 1/3 i18n: Fixes uncatchable comments for translators
Comment for l10n translators can not be extracted by xgettext if it is not right above the l10n tag. Moving the comment right before the l10n tag will fix this issue.
--- date.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
date.c +1 -1
@@ -144,8 +144,8 @@ void show_date_relative(unsigned long time, int tz,if (months) {struct strbuf sb =STRBUF_INIT ;strbuf_addf (&sb,Q_ ("%lu year" ,"%lu years" , years), years); -/* TRANSLATORS: "%s" is "<n> years" */ strbuf_addf (timebuf, +/* TRANSLATORS: "%s" is "<n> years" */ Q_ ("%s, %lu month ago" ,"%s, %lu months ago" , months), sb.buf, months);strbuf_release (&sb);
Signature · 1 line
1.9.2.461.g942803f
PATCH 2/3 i18n: Only extract comments marked by special tag
In reply to Jiang XinWhen extract l10n messages, we use "--add-comments" option to keep comments right above the l10n messages for references. But sometimes irrelevant comments are also extracted. For example in the following code block, the comment in line 2 will be extracted as comment for the l10n message in line 3, but obviously it's wrong.
{ OPTION_CALLBACK, 0, "ignore-removal", &addremove_explicit,
NULL /* takes no arguments */,
N_("ignore paths removed in the working tree (same as --no-all)"),
PARSE_OPT_NOARG, ignore_removal_cb },
Since almost all comments for l10n translators are marked with the same prefix (tag): "TRANSLATORS:", it's safe to only extract comments with this special tag. I.E. it's better to call xgettext as:
xgettext --add-comments=TRANSLATORS: ...
Also tweaks the multi-line comment in "init-db.c", to make it start with the proper tag, not "* TRANSLATORS:" (which has a star before the tag).
--- Makefile | 2 +- builtin/init-db.c | 8 +++----- 2 files changed, 4 insertions(+), 6 deletions(-)
Makefile +1 -1
@@ -2102,7 +2102,7 @@ pdf: XGETTEXT_FLAGS = \ --force-po \ - --add-comments \ + --add-comments=TRANSLATORS: \ --msgid-bugs-address="Git Mailing List <[email protected]>" \ --from-code=UTF-8 XGETTEXT_FLAGS_C = $(XGETTEXT_FLAGS) --language=C \
builtin/init-db.c +3 -5
@@ -412,11 +412,9 @@ int init_db(const char *template_dir, unsigned int flags)if (!(flags &INIT_DB_QUIET )) {int len =strlen (git_dir); -/* -* TRANSLATORS: The first '%s' is either "Reinitialized -* existing" or "Initialized empty", the second " shared" or -* "", and the last '%s%s' is the verbatim directory name. -*/ +/* TRANSLATORS: The first '%s' is either "Reinitialized +existing" or "Initialized empty", the second " shared" or +"", and the last '%s%s' is the verbatim directory name. */ printf(_("%s%s Git repository in %s%s\n"), reinit ? _("Reinitialized existing") : _("Initialized empty"), shared_repository ? _(" shared") : "",
Signature · 1 line
1.9.2.461.g942803f
Re: [PATCH 2/3] i18n: Only extract comments marked by special tag
Quoted 12 lines · Jiang Xin
When extract l10n messages, we use "--add-comments" option to keep comments right above the l10n messages for references. But sometimes irrelevant comments are also extracted. For example in the following code block, the comment in line 2 will be extracted as comment for the l10n message in line 3, but obviously it's wrong.
{
OPTION_CALLBACK, 0, "ignore-removal",&addremove_explicit,
NULL /* takes no arguments */,
N_("ignore paths removed in the working tree (same as --no-all)"),
PARSE_OPT_NOARG,ignore_removal_cb},
Quoted 8 lines
Since almost all comments for l10n translators are marked with the same prefix (tag): "TRANSLATORS:", it's safe to only extract comments with this special tag. I.E. it's better to call xgettext as:
xgettext --add-comments=TRANSLATORS: ...Also tweaks the multi-line comment in "
init-db.c", to make it start with the proper tag, not "* TRANSLATORS:" (which has a star before the tag).
Hmph.
I am not very happy with this change, as it would force us to special case "Translators" comment to follow a non-standard multi-line comment formatting convention. Is there a way to tell xgettext to accept both of these forms?
/* TRANSLATORS: this is a short comment to help you */
_("foo bar");
/*
* TRANSLATORS: this comment is to help you, but it is
* a lot longer to fit on just a single line.
*/
_("bar baz");Quoted 39 lines
Signed-off-by Jiang Xin <[email protected]>--- Makefile | 2 +- builtin/init-db.c | 8 +++----- 2 files changed, 4 insertions(+), 6 deletions(-)Makefile +1
-1@@ -2102,7 +2102,7 @@ pdf: XGETTEXT_FLAGS = \ --force-po \ - --add-comments \ + --add-comments=TRANSLATORS: \ --msgid-bugs-address="Git Mailing List <[email protected]>" \ --from-code=UTF-8 XGETTEXT_FLAGS_C = $(XGETTEXT_FLAGS) --language=C \builtin/init-db.c +3
-5@@ -412,11 +412,9 @@ int init_db(const char *template_dir, unsigned int flags)if (!(flags &INIT_DB_QUIET )) {int len =strlen (git_dir); -/* -* TRANSLATORS: The first '%s' is either "Reinitialized -* existing" or "Initialized empty", the second " shared" or -* "", and the last '%s%s' is the verbatim directory name. -*/ +/* TRANSLATORS: The first '%s' is either "Reinitialized +existing" or "Initialized empty", the second " shared" or +"", and the last '%s%s' is the verbatim directory name. */ printf(_("%s%s Git repository in %s%s\n"), reinit ? _("Reinitialized existing") : _("Initialized empty"), shared_repository ? _(" shared") : "",
Re: [PATCH 2/3] i18n: Only extract comments marked by special tag
2014-04-18 2:08 GMT+08:00 Junio C Hamano <[email protected]>:
Quoted 30 lines
Quoted 12 lines · Jiang Xin
When extract l10n messages, we use "--add-comments" option to keep comments right above the l10n messages for references. But sometimes irrelevant comments are also extracted. For example in the following code block, the comment in line 2 will be extracted as comment for the l10n message in line 3, but obviously it's wrong.
{
OPTION_CALLBACK, 0, "ignore-removal",&addremove_explicit,
NULL /* takes no arguments */,
N_("ignore paths removed in the working tree (same as --no-all)"),
PARSE_OPT_NOARG,ignore_removal_cb},Quoted 8 lines
Since almost all comments for l10n translators are marked with the same prefix (tag): "TRANSLATORS:", it's safe to only extract comments with this special tag. I.E. it's better to call xgettext as:
xgettext --add-comments=TRANSLATORS: ...Also tweaks the multi-line comment in "
init-db.c", to make it start with the proper tag, not "* TRANSLATORS:" (which has a star before the tag).Hmph.
I am not very happy with this change, as it would force us to special case "Translators" comment to follow a non-standard multi-line comment formatting convention. Is there a way to tell xgettext to accept both of these forms?
Quoted 9 lines
/* TRANSLATORS: this is a short comment to help you */
_("foo bar");
/*
* TRANSLATORS: this comment is to help you, but it is
* a lot longer to fit on just a single line.
*/
_("bar baz");We can not provide multiple --add-comments=TAG options to xgettext, because xgettext holds the tag in one string, not in a list:
/* Tag used in comment of prevailing domain. */
static char *comment_tag;So if we won't change our multi-line comments for translators, must hack gettext in some ways.
There maybe 3 ways to hack gettext:
1. When matching comments against TAG, using strstr not strncmp.
2360 /* When the comment tag is seen, it drags in not
only the line
2361 which it starts, but all remaining comment lines. */
2362 if (add_all_remaining_comments
2363 || (add_all_remaining_comments =
2364 (comment_tag != NULL
2365 && strncmp (s, comment_tag, strlen(comment_tag)) == 0)))
2. Add a extension to in-comment xgettext instructions.
There is a undocumented feature in xgettext: User can provide instructions (prefixed by xgettext:) in comments, such as:
/*
* xgettext: fuzzy possible-c-format no-wrap
* other comments...
*/
But it does not help much, unless we hack xgettext to extend this hidden feature. I.E. Add an additional flag to support unconditionally reference to the commit block. Like:
/*
* xgettext: comments
* TRANSLATORS: this comment is to help you, but it is
* a lot longer to fit on just a single line. */
_("bar baz");
3. Hack the parser for comments in "gettext-tools/src/x-c.c" (maybe function phase4_getc()) to support various multi-line comments style, such as:
/*
* TRANSLATORS: this comment is to help you, but it is
* a lot longer to fit on just a single line. */
/*
** TRANSLATORS: this comment is to help you, but it is ** a lot longer to fit on just a single line. */
/********************************************************
* TRANSLATORS: this comment is to help you, but it is *
* a lot longer to fit on just a single line. *
********************************************************/
I CC this mail to the gettext mailing list. Full thread see:
* http://thread.gmane.org/gmane.comp.version-control.git/246390/focus=246431
Signature · 1 line
Jiang Xin
Re: [PATCH 2/3] i18n: Only extract comments marked by special tag
Quoted 21 lines · Jiang Xin
Quoted 5 lines
I am not very happy with this change, as it would force us to special case "Translators" comment to follow a non-standard multi-line comment formatting convention. Is there a way to tell xgettext to accept both of these forms?
Quoted 9 lines
/* TRANSLATORS: this is a short comment to help you */ _("foo bar"); /* * TRANSLATORS: this comment is to help you, but it is * a lot longer to fit on just a single line. */ _("bar baz");We can not provide multiple
--add-comments=TAGoptions to xgettext, because xgettext holds the tag in one string, not in a list:/* Tag used in comment of prevailing domain. */ static char *comment_tag;
Quoted 8 lines
So if we won't change our multi-line comments for translators, must hack gettext in some ways.
There maybe 3 ways to hack gettext:
...
I CC this mail to the gettext mailing list. Full thread see:* http://thread.gmane.org/gmane.comp.version-control.git/246390/focus=246431
This is one of these times when I find myself very fortunate for being surrounded by competent contributors with good tastes, which I may not deserve ;-)
Thanks for being thorough.
Having said that, it is only just a single comment, and it is too much hassle to even think about what to do in the meantime while we wait until such a change happens and an updated version of gettext reaches everybody. Let's take 2/3 as-is.
Documentation/CodingGuidelines may want to have a sentence of two to explain this, though.
Documentation/CodingGuidelines | 9 +++++++++ 1 file changed, 9 insertions(+)
Documentation/CodingGuidelines +9 -0
@@ -159,10 +159,19 @@ For C programs: - Multi-line comments include their delimiters on separate lines from the text. E.g. /* * A very long * multi-line comment. */ + Note however that a multi-line comment that explains a translatable + string to translators uses a different convention of starting with a + magic token "TRANSLATORS: " immediately after the opening delimiter, + and without an asterisk at the beginning of each line. E.g. + + /* TRANSLATORS: here is a comment that explains the string + to be translated, that follows immediately after it */ + _("Here is a translatable string explained by the above."); + - Double negation is often harder to understand than no negation at all.
Re: [PATCH 2/3] i18n: Only extract comments marked by special tag
Quoted 2 lines · Junio C Hamano
Documentation/CodingGuidelinesmay want to have a sentence of two to explain this, though.
After re-reading what I sent out, I realized that the way I singled out multi-line comments was misleading. Here is an updated version.
-- >8 --
Subject: [PATCH] i18n: mention "TRANSLATORS:" marker in Documentation/CodingGuidelines
These comments have to have "TRANSLATORS: " at the very beginning and have to deviate from the usual multi-line comment formatting convention.
--- Documentation/CodingGuidelines | 10 ++++++++++ 1 file changed, 10 insertions(+)
Documentation/CodingGuidelines +10 -0
@@ -164,6 +164,16 @@ For C programs: * multi-line comment. */ + Note however that a comment that explains a translatable string to + translators uses a convention of starting with a magic token + "TRANSLATORS: " immediately after the opening delimiter, even when + it spans multiple lines. We do not add an asterisk at the beginning + of each line, either. E.g. + + /* TRANSLATORS: here is a comment that explains the string + to be translated, that follows immediately after it */ + _("Here is a translatable string explained by the above."); + - Double negation is often harder to understand than no negation at all.
Signature · 1 line
1.9.2-651-g78816bc
Re: [PATCH 0/3] extract proper comments for l10n translators
In reply to Jiang Xin2014-04-17 13:37 GMT+08:00 Jiang Xin <[email protected]>:
Quoted 3 lines
When generate git.pot, many irrelevant comments are extracted as references for translators, but one useful comment is lost. This series patches will fix this issue.
Brief changes of po/git.pot after applied these patches:
po/git.pot +5 -40
@@ -23,10 +23,6 @@ msgstr "" msgid "hint: %.*s\n" msgstr "" -#. -#. * Message used both when 'git commit' fails and when -#. * other commands doing a merge do. -#. #: advice.c:85 msgid "" "Fix them up in the work tree,\n"
@@ -399,6 +395,7 @@ msgid_plural "%lu years" msgstr[0] "" msgstr[1] "" +#. TRANSLATORS: "%s" is "<n> years" #: date.c:149 #, c-format msgid "%s, %lu month ago"
@@ -582,8 +579,6 @@ msgstr "" msgid "Removing %s to make room for subdirectory\n" msgstr "" -#. something else exists -#. .. but not some other error (who really cares what?) #: merge-recursive.c:700 merge-recursive.c:721 msgid ": perhaps a D/F conflict?" msgstr ""
@@ -899,11 +894,6 @@ msgstr "" msgid "Pathspec '%s' is in submodule '%.*s'" msgstr "" -#. -#. * We may want to substitute "this command" with a command -#. * name. E.g. when add--interactive dies when running -#. * "checkout -p" -#. #: pathspec.c:353 #, c-format msgid "%s: pathspec magic not supported by this command: %s"
@@ -953,11 +943,6 @@ msgstr "" msgid "%s tracks both %s and %s" msgstr "" -#. -#. * This last possibility doesn't occur because -#. * FETCH_HEAD_IGNORE entries always appear at -#. * the end of the list. -#. #: remote.c:774 msgid "Internal error" msgstr ""
@@ -1306,13 +1291,11 @@ msgstr "" msgid "Could not find section in .gitmodules where path=%s" msgstr "" -#. Maybe the user already did that, don't error out here #: submodule.c:76 #, c-format msgid "Could not update .gitmodules entry %s" msgstr "" -#. Maybe the user already did that, don't error out here #: submodule.c:109 #, c-format msgid "Could not remove .gitmodules entry for %s"
@@ -1884,7 +1867,6 @@ msgstr "" msgid "add changes from all tracked and untracked files" msgstr "" -#. takes no arguments #: builtin/add.c:260 msgid "ignore paths removed in the working tree (same as --no-all)" msgstr ""
@@ -2044,7 +2026,6 @@ msgstr "" msgid "corrupt binary patch at line %d: %.*s" msgstr "" -#. there has to be one hunk (forward hunk) #: builtin/apply.c:1900 #, c-format msgid "unrecognized binary patch at line %d"
@@ -2232,7 +2213,6 @@ msgstr "" msgid "internal error" msgstr "" -#. Say this even without --verbose #: builtin/apply.c:4043 #, c-format msgid "Applying patch %%s with %d reject..."
@@ -3232,7 +3212,6 @@ msgstr "" msgid " ... and %d more.\n" msgstr "" -#. The singular version #: builtin/checkout.c:711 #, c-format msgid ""
@@ -3280,7 +3259,6 @@ msgstr "" msgid "invalid reference: %s" msgstr "" -#. case (1): want a tree #: builtin/checkout.c:1002 #, c-format msgid "reference is not a tree: %s"
@@ -4276,7 +4254,6 @@ msgstr "" msgid "GPG sign commit" msgstr "" -#. end commit message options #: builtin/commit.c:1508 msgid "Commit contents options" msgstr ""
@@ -5140,7 +5117,6 @@ msgstr "" msgid "See \"git help gc\" for manual housekeeping.\n" msgstr "" -#. be quiet on --auto #: builtin/gc.c:336 #, c-format msgid ""
@@ -5894,12 +5870,10 @@ msgstr "" msgid "unable to move %s to %s" msgstr "" -#. -#. * TRANSLATORS: The first '%s' is either "Reinitialized -#. * existing" or "Initialized empty", the second " shared" or -#. * "", and the last '%s%s' is the verbatim directory name. -#. -#: builtin/init-db.c:420 +#. TRANSLATORS: The first '%s' is either "Reinitialized +#. existing" or "Initialized empty", the second " shared" or +#. "", and the last '%s%s' is the verbatim directory name. +#: builtin/init-db.c:418 #, c-format msgid "%s%s Git repository in %s%s\n" msgstr ""
@@ -6627,7 +6601,6 @@ msgstr "" msgid "Commit %s has a bad GPG signature allegedly by %s." msgstr "" -#. 'N' #: builtin/merge.c:1279 #, c-format msgid "Commit %s does not have a GPG signature."
@@ -9593,8 +9566,6 @@ msgstr "" msgid "'git bisect bad' can take only one argument." msgstr "" -#. have bad but not good. we could bisect although -#. this is less optimum. #: git-bisect.sh:273 msgid "Warning: bisecting only with a bad commit." msgstr ""
@@ -9690,10 +9661,6 @@ msgstr "" msgid "updating an unborn branch with changes added to the index" msgstr "" -#. The fetch involved updating the current branch. -#. The working tree and the index file is still based on the -#. $orig_head commit, but we are merging into $curr_head. -#. First update the working tree to match $curr_head. #: git-pull.sh:271 #, sh-format msgid ""
@@ -9835,7 +9802,6 @@ msgstr "" msgid "Changes from $mb to $onto:" msgstr "" -#. Detach HEAD and reset the tree #: git-rebase.sh:609 msgid "First, rewinding head to replay your work on top of it..." msgstr ""
@@ -10218,7 +10184,6 @@ msgstr "" msgid "The --cached option cannot be used with the --files option" msgstr "" -#. unexpected type #: git-submodule.sh:1097 #, sh-format msgid "unexpected mode $mod_dst"
Signature · 1 line
Jiang Xin
Re: [PATCH 0/3] extract proper comments for l10n translators
Quoted 6 lines · Jiang Xin
2014-04-17 13:37 GMT+08:00 Jiang Xin <[email protected]>:
Quoted 3 lines
When generate git.pot, many irrelevant comments are extracted as references for translators, but one useful comment is lost. This series patches will fix this issue.
Brief changes of po/git.pot after applied these patches:
This is a very good way to make sure that 2/3 does not lose helpful comments.
Thanks, but my complaint regarding the multi-line comment format still stands.
Quoted 188 lines
po/git.pot +5
-40@@ -23,10 +23,6 @@ msgstr "" msgid "hint: %.*s\n" msgstr "" -#. -#. * Message used both when 'git commit' fails and when -#. * other commands doing a merge do. -#. #: advice.c:85 msgid "" "Fix them up in the work tree,\n"@@ -399,6 +395,7 @@ msgid_plural "%lu years" msgstr[0] "" msgstr[1] "" +#. TRANSLATORS: "%s" is "<n> years" #: date.c:149 #, c-format msgid "%s, %lu month ago"@@ -582,8 +579,6 @@ msgstr "" msgid "Removing %s to make room for subdirectory\n" msgstr "" -#. something else exists -#. .. but not some other error (who really cares what?) #: merge-recursive.c:700 merge-recursive.c:721 msgid ": perhaps a D/F conflict?" msgstr ""@@ -899,11 +894,6 @@ msgstr "" msgid "Pathspec '%s' is in submodule '%.*s'" msgstr "" -#. -#. * We may want to substitute "this command" with a command -#. * name. E.g. when add--interactive dies when running -#. * "checkout -p" -#. #: pathspec.c:353 #, c-format msgid "%s: pathspec magic not supported by this command: %s"@@ -953,11 +943,6 @@ msgstr "" msgid "%s tracks both %s and %s" msgstr "" -#. -#. * This last possibility doesn't occur because -#. * FETCH_HEAD_IGNORE entries always appear at -#. * the end of the list. -#. #: remote.c:774 msgid "Internal error" msgstr ""@@ -1306,13 +1291,11 @@ msgstr "" msgid "Could not find section in .gitmodules where path=%s" msgstr "" -#. Maybe the user already did that, don't error out here #: submodule.c:76 #, c-format msgid "Could not update .gitmodules entry %s" msgstr "" -#. Maybe the user already did that, don't error out here #: submodule.c:109 #, c-format msgid "Could not remove .gitmodules entry for %s"@@ -1884,7 +1867,6 @@ msgstr "" msgid "add changes from all tracked and untracked files" msgstr "" -#. takes no arguments #: builtin/add.c:260 msgid "ignore paths removed in the working tree (same as --no-all)" msgstr ""@@ -2044,7 +2026,6 @@ msgstr "" msgid "corrupt binary patch at line %d: %.*s" msgstr "" -#. there has to be one hunk (forward hunk) #: builtin/apply.c:1900 #, c-format msgid "unrecognized binary patch at line %d"@@ -2232,7 +2213,6 @@ msgstr "" msgid "internal error" msgstr "" -#. Say this even without --verbose #: builtin/apply.c:4043 #, c-format msgid "Applying patch %%s with %d reject..."@@ -3232,7 +3212,6 @@ msgstr "" msgid " ... and %d more.\n" msgstr "" -#. The singular version #: builtin/checkout.c:711 #, c-format msgid ""@@ -3280,7 +3259,6 @@ msgstr "" msgid "invalid reference: %s" msgstr "" -#. case (1): want a tree #: builtin/checkout.c:1002 #, c-format msgid "reference is not a tree: %s"@@ -4276,7 +4254,6 @@ msgstr "" msgid "GPG sign commit" msgstr "" -#. end commit message options #: builtin/commit.c:1508 msgid "Commit contents options" msgstr ""@@ -5140,7 +5117,6 @@ msgstr "" msgid "See \"git help gc\" for manual housekeeping.\n" msgstr "" -#. be quiet on --auto #: builtin/gc.c:336 #, c-format msgid ""@@ -5894,12 +5870,10 @@ msgstr "" msgid "unable to move %s to %s" msgstr "" -#. -#. * TRANSLATORS: The first '%s' is either "Reinitialized -#. * existing" or "Initialized empty", the second " shared" or -#. * "", and the last '%s%s' is the verbatim directory name. -#. -#: builtin/init-db.c:420 +#. TRANSLATORS: The first '%s' is either "Reinitialized +#. existing" or "Initialized empty", the second " shared" or +#. "", and the last '%s%s' is the verbatim directory name. +#: builtin/init-db.c:418 #, c-format msgid "%s%s Git repository in %s%s\n" msgstr ""@@ -6627,7 +6601,6 @@ msgstr "" msgid "Commit %s has a bad GPG signature allegedly by %s." msgstr "" -#. 'N' #: builtin/merge.c:1279 #, c-format msgid "Commit %s does not have a GPG signature."@@ -9593,8 +9566,6 @@ msgstr "" msgid "'git bisect bad' can take only one argument." msgstr "" -#. have bad but not good. we could bisect although -#. this is less optimum. #: git-bisect.sh:273 msgid "Warning: bisecting only with a bad commit." msgstr ""@@ -9690,10 +9661,6 @@ msgstr "" msgid "updating an unborn branch with changes added to the index" msgstr "" -#. The fetch involved updating the current branch. -#. The working tree and the index file is still based on the -#. $orig_head commit, but we are merging into $curr_head. -#. First update the working tree to match $curr_head. #: git-pull.sh:271 #, sh-format msgid ""@@ -9835,7 +9802,6 @@ msgstr "" msgid "Changes from $mb to $onto:" msgstr "" -#. Detach HEAD and reset the tree #: git-rebase.sh:609 msgid "First, rewinding head to replay your work on top of it..." msgstr ""@@ -10218,7 +10184,6 @@ msgstr "" msgid "The --cached option cannot be used with the --files option" msgstr "" -#. unexpected type #: git-submodule.sh:1097 #, sh-format msgid "unexpected mode $mod_dst"
PATCH 3/3 i18n: Remove obsolete comments for translators
In reply to Jiang XinSince we do not translate diffstat any more, remove the obsolete comments.
--- diff.c | 8 -------- 1 file changed, 8 deletions(-)
diff.c +0 -8
@@ -1461,20 +1461,12 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)* but nothing about added/removed lines? Is this a bug in Git?"). */ if (insertions || deletions ==0 ) { -/* -* TRANSLATORS: "+" in (+) is a line addition marker; -* do not translate it. -*/ strbuf_addf (&sb, (insertions ==1 ) ?", %d insertion(+)" :", %d insertions(+)" , insertions); }if (deletions || insertions ==0 ) { -/* -* TRANSLATORS: "-" in (-) is a line removal marker; -* do not translate it. -*/ strbuf_addf (&sb, (deletions ==1 ) ?", %d deletion(-)" :", %d deletions(-)" , deletions);
Signature · 1 line
1.9.2.461.g942803f