[PATCH 1/1] Mark messages for translations
Small changes in messages to fit the style and typography of rest.
Reuse already translated messages if possible.
Do not translate messages aimed at developers of git.
Fix unit tests depending on the original string.
Use `test_i18ngrep` for tests with translatable strings.
Change and verify rest of tests via `make GETTEXT_POISON=1 test`.
Signed-off-by: Alexander Shopov <a...@kambanaria.org>
---
git.c | 38 +-
setup.c| 62 +-
t/t0002-gitfile.sh | 4 +--
t/t0008-ignores.sh | 2 +-
t/t1506-rev-parse-diagnosis.sh | 2 +-
5 files changed, 54 insertions(+), 54 deletions(-)
diff --git a/git.c b/git.c
index c870b9719..5ddcb75d4 100644
--- a/git.c
+++ b/git.c
@@ -5,11 +5,11 @@
#include "run-command.h"
const char git_usage_string[] =
- "git [--version] [--help] [-C ] [-c name=value]\n"
- " [--exec-path[=]] [--html-path] [--man-path]
[--info-path]\n"
- " [-p | --paginate | --no-pager] [--no-replace-objects]
[--bare]\n"
- " [--git-dir=] [--work-tree=]
[--namespace=]\n"
- "[]";
+ N_("git [--version] [--help] [-C ] [-c =]\n"
+ " [--exec-path[=]] [--html-path] [--man-path]
[--info-path]\n"
+ " [-p | --paginate | --no-pager] [--no-replace-objects]
[--bare]\n"
+ " [--git-dir=] [--work-tree=]
[--namespace=]\n"
+ "[]");
const char git_more_info_string[] =
N_("'git help -a' and 'git help -g' list available subcommands and
some\n"
@@ -92,7 +92,7 @@ static int handle_options(const char ***argv, int *argc, int
*envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--git-dir")) {
if (*argc < 2) {
- fprintf(stderr, "No directory given for
--git-dir.\n" );
+ fprintf(stderr, _("no directory given for
--git-dir\n" ));
usage(git_usage_string);
}
setenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);
@@ -106,7 +106,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--namespace")) {
if (*argc < 2) {
- fprintf(stderr, "No namespace given for
--namespace.\n" );
+ fprintf(stderr, _("no namespace given for
--namespace\n" ));
usage(git_usage_string);
}
setenv(GIT_NAMESPACE_ENVIRONMENT, (*argv)[1], 1);
@@ -120,7 +120,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--work-tree")) {
if (*argc < 2) {
- fprintf(stderr, "No directory given for
--work-tree.\n" );
+ fprintf(stderr, _("no directory given for
--work-tree\n" ));
usage(git_usage_string);
}
setenv(GIT_WORK_TREE_ENVIRONMENT, (*argv)[1], 1);
@@ -134,7 +134,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--super-prefix")) {
if (*argc < 2) {
- fprintf(stderr, "No prefix given for
--super-prefix.\n" );
+ fprintf(stderr, _("no prefix given for
--super-prefix\n" ));
usage(git_usage_string);
}
setenv(GIT_SUPER_PREFIX_ENVIRONMENT, (*argv)[1], 1);
@@ -156,7 +156,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "-c")) {
if (*argc < 2) {
- fprintf(stderr, "-c expects a configuration
string\n" );
+ fprintf(stderr, _("-c expects a configuration
string\n" ));
usage(git_usage_string);
}
git_config_push_parameter((*argv)[1]);
@@ -194,12 +194,12 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
[PATCH 0/1] Mark messages for translation
Following suggestions on last email exchange: Junio C Hamano 1. End sentences in long log message with '.' 2. Leave final merge fixes to him based on suggestion from Jeff King Previous changes: Eric Sunshine: 1. Use 'test_i18ngrep' rather than 'grep' Jeff King: 2. Fix t1506 Johannes Sixt: 3. Lower-case letters at the beginning of error messages 4. Past tense to present tense in some cases Eric Sunshine: 5. Fix `-cname=value` to say `-c =` 6. Do not translate "BUG message" Duy Nguyen: 7. Fix parentheses on `_` macro Kind regards: al_shopov Alexander Shopov (1): Mark messages for translations git.c | 38 +- setup.c| 62 +- t/t0002-gitfile.sh | 4 +-- t/t0008-ignores.sh | 2 +- t/t1506-rev-parse-diagnosis.sh | 2 +- 5 files changed, 54 insertions(+), 54 deletions(-) -- 2.16.1
Re: [PATCH 1/1] Mark messages for translations
Let me repeat what you said so I know how to improve the patch: @Junio: > Perhaps end each sentence with a full-stop? I should end each sentence in the *log* message with "." (rather than the translatable strings in the patch) > Shouldn't this rather be like so instead? > if test_i18ngrep ! "invalid gitfile format" .err ... > These two ones want to be written The standard negation form is: test_i18ngrep ! but I should leave the `!` in front of `test_i18ngrep` in this particular case @Jeff: > we may want to avoid this anti-pattern Current state of these tests is wrong and I should rework them. Here is what I intend to do: 1. Fix the commit message 2. Check whether I can get the tests in t0002-gitfile.sh to the standard `test_i18ngrep !` negative (i.e. without using `if`) 3. Post and ask for feedback again Kind regards: al_shopov
[PATCH 1/1] Mark messages for translations
Small changes in messages to fit the style and typography of rest
Reuse already translated messages if possible
Do not translate messages aimed at developers of git
Fix unit tests depending on the original string
Use `test_i18ngrep` for tests with translatable strings
Change and verifyrest of tests via `make GETTEXT_POISON=1 test`
Signed-off-by: Alexander Shopov <a...@kambanaria.org>
---
git.c | 38 +-
setup.c| 62 +-
t/t0002-gitfile.sh | 4 +--
t/t0008-ignores.sh | 2 +-
t/t1506-rev-parse-diagnosis.sh | 2 +-
5 files changed, 54 insertions(+), 54 deletions(-)
diff --git a/git.c b/git.c
index c870b9719..5ddcb75d4 100644
--- a/git.c
+++ b/git.c
@@ -5,11 +5,11 @@
#include "run-command.h"
const char git_usage_string[] =
- "git [--version] [--help] [-C ] [-c name=value]\n"
- " [--exec-path[=]] [--html-path] [--man-path]
[--info-path]\n"
- " [-p | --paginate | --no-pager] [--no-replace-objects]
[--bare]\n"
- " [--git-dir=] [--work-tree=]
[--namespace=]\n"
- "[]";
+ N_("git [--version] [--help] [-C ] [-c =]\n"
+ " [--exec-path[=]] [--html-path] [--man-path]
[--info-path]\n"
+ " [-p | --paginate | --no-pager] [--no-replace-objects]
[--bare]\n"
+ " [--git-dir=] [--work-tree=]
[--namespace=]\n"
+ "[]");
const char git_more_info_string[] =
N_("'git help -a' and 'git help -g' list available subcommands and
some\n"
@@ -92,7 +92,7 @@ static int handle_options(const char ***argv, int *argc, int
*envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--git-dir")) {
if (*argc < 2) {
- fprintf(stderr, "No directory given for
--git-dir.\n" );
+ fprintf(stderr, _("no directory given for
--git-dir\n" ));
usage(git_usage_string);
}
setenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);
@@ -106,7 +106,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--namespace")) {
if (*argc < 2) {
- fprintf(stderr, "No namespace given for
--namespace.\n" );
+ fprintf(stderr, _("no namespace given for
--namespace\n" ));
usage(git_usage_string);
}
setenv(GIT_NAMESPACE_ENVIRONMENT, (*argv)[1], 1);
@@ -120,7 +120,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--work-tree")) {
if (*argc < 2) {
- fprintf(stderr, "No directory given for
--work-tree.\n" );
+ fprintf(stderr, _("no directory given for
--work-tree\n" ));
usage(git_usage_string);
}
setenv(GIT_WORK_TREE_ENVIRONMENT, (*argv)[1], 1);
@@ -134,7 +134,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--super-prefix")) {
if (*argc < 2) {
- fprintf(stderr, "No prefix given for
--super-prefix.\n" );
+ fprintf(stderr, _("no prefix given for
--super-prefix\n" ));
usage(git_usage_string);
}
setenv(GIT_SUPER_PREFIX_ENVIRONMENT, (*argv)[1], 1);
@@ -156,7 +156,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "-c")) {
if (*argc < 2) {
- fprintf(stderr, "-c expects a configuration
string\n" );
+ fprintf(stderr, _("-c expects a configuration
string\n" ));
usage(git_usage_string);
}
git_config_push_parameter((*argv)[1]);
@@ -194,12 +194,12 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
[PATCH 0/1] Mark messages for translations
Hi all, Continuing with ths suggestions for improvements. Racap since last time: Eric Sunshine: 1. Use 'test_i18ngrep' rather than 'grep' Jeff King: 2. Fix t1506 Previous changes: Johannes Sixt: 1. Lower-case letters at the beginning of error messages 2. Past tense to present tense in some cases Eric Sunshine: 3. Fix `-cname=value` to say `-c =` 4. Do not translate "BUG message" Duy Nguyen: 5. Fix parentheses on `_` macro Kind regards: al_shopov Alexander Shopov (1): Mark messages for translations git.c | 38 +- setup.c| 62 +- t/t0002-gitfile.sh | 4 +-- t/t0008-ignores.sh | 2 +- t/t1506-rev-parse-diagnosis.sh | 2 +- 5 files changed, 54 insertions(+), 54 deletions(-) -- 2.16.1
[PATCH 1/1] Mark messages for translations
Small changes in messages to fit the style and typography of rest
Reuse already translated messages if possible
Do not translate messages aimed at developers of git
Fix unit tests depending on the original string
Signed-off-by: Alexander Shopov <a...@kambanaria.org>
---
git.c | 38 -
setup.c| 62 +++---
t/t0002-gitfile.sh | 4 ++--
t/t0008-ignores.sh | 2 +-
4 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/git.c b/git.c
index c870b9719..5ddcb75d4 100644
--- a/git.c
+++ b/git.c
@@ -5,11 +5,11 @@
#include "run-command.h"
const char git_usage_string[] =
- "git [--version] [--help] [-C ] [-c name=value]\n"
- " [--exec-path[=]] [--html-path] [--man-path]
[--info-path]\n"
- " [-p | --paginate | --no-pager] [--no-replace-objects]
[--bare]\n"
- " [--git-dir=] [--work-tree=]
[--namespace=]\n"
- "[]";
+ N_("git [--version] [--help] [-C ] [-c =]\n"
+ " [--exec-path[=]] [--html-path] [--man-path]
[--info-path]\n"
+ " [-p | --paginate | --no-pager] [--no-replace-objects]
[--bare]\n"
+ " [--git-dir=] [--work-tree=]
[--namespace=]\n"
+ "[]");
const char git_more_info_string[] =
N_("'git help -a' and 'git help -g' list available subcommands and
some\n"
@@ -92,7 +92,7 @@ static int handle_options(const char ***argv, int *argc, int
*envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--git-dir")) {
if (*argc < 2) {
- fprintf(stderr, "No directory given for
--git-dir.\n" );
+ fprintf(stderr, _("no directory given for
--git-dir\n" ));
usage(git_usage_string);
}
setenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);
@@ -106,7 +106,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--namespace")) {
if (*argc < 2) {
- fprintf(stderr, "No namespace given for
--namespace.\n" );
+ fprintf(stderr, _("no namespace given for
--namespace\n" ));
usage(git_usage_string);
}
setenv(GIT_NAMESPACE_ENVIRONMENT, (*argv)[1], 1);
@@ -120,7 +120,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--work-tree")) {
if (*argc < 2) {
- fprintf(stderr, "No directory given for
--work-tree.\n" );
+ fprintf(stderr, _("no directory given for
--work-tree\n" ));
usage(git_usage_string);
}
setenv(GIT_WORK_TREE_ENVIRONMENT, (*argv)[1], 1);
@@ -134,7 +134,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--super-prefix")) {
if (*argc < 2) {
- fprintf(stderr, "No prefix given for
--super-prefix.\n" );
+ fprintf(stderr, _("no prefix given for
--super-prefix\n" ));
usage(git_usage_string);
}
setenv(GIT_SUPER_PREFIX_ENVIRONMENT, (*argv)[1], 1);
@@ -156,7 +156,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "-c")) {
if (*argc < 2) {
- fprintf(stderr, "-c expects a configuration
string\n" );
+ fprintf(stderr, _("-c expects a configuration
string\n" ));
usage(git_usage_string);
}
git_config_push_parameter((*argv)[1]);
@@ -194,12 +194,12 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "-C")) {
if (*argc < 2) {
- fprintf(stderr, "No directory given for -C.\n"
);
+
[PATCH 0/1] Mark messages for translations
*** BLURB HERE *** Hi all, Again I am marking messages for translations in gui.c and setup.c based on the feedback I got last time. Now I am fixing unit tests as well, hopefully no regressions. Here is a recap: Johannes Sixt: 1. Lower-case letters at the beginning of error messages 2. Past tense to present tense in some cases Eric Sunshine: 3. Fix `-cname=value` to say `-c =` 4. Do not translate "BUG message" Duy Nguyen: 5. Fix parentheses on `_` macro Kind regards: al_shopov Alexander Shopov (1): Mark messages for translations git.c | 38 - setup.c| 62 +++--- t/t0002-gitfile.sh | 4 ++-- t/t0008-ignores.sh | 2 +- 4 files changed, 53 insertions(+), 53 deletions(-) -- 2.16.1
Re: [PATCH 1/1] Mark messages for translations
And again, sigh:
>> const char git_usage_string[] =
>> const char git_more_info_string[] =
> It is not obvious to me where git_usage_string is looked up in the
> message catalog. It is used that way in builtin/help.c ..
I wanted to be consistent with the current state of the file. This is the
same way const char git_more_info_string[] is defined and initialized.
Having it this way saves the lookup on each usage I guess but any performance
gains will be negligible. Is there a convention?
> We have settled with lower-case letters at the beginning of error
> messages. (See Documentation/CodingGuidelines, "Error Messages".) You
> could fix that while you are touching die, die_errno, etc, messages.
Great! It will allow for further reduction in repetition of messages.
> I notice you change past tense to present tense in some cases.
I am reading this that messages SHOULD be in present tense (unless they MUST
be in past tense). This is good. Perhaps I will look at current messages and
then fix en masse (if there is sth to fix).
> I'm not a friend of geeky abbreviations like "chdir" or "cwd" in
> user-visible messages
I agree but I would also keep in mind that using the name of the function
may alllow to parametrize the messages like:
Cannot execute "%s" on "%s" - for example. Anyway this is not that important
for me. Will wait for other opinions.
>> - die_errno("fork failed");
>> + die_errno(_("fork failed"));
>> - die_errno("setsid failed");
>> + die_errno(_("setsid failed"));
> it is useful to have the function name in the message. Which rises the
> question:why translate them at all?
Why not eat the cake while having it - one can pass function name in a
message like: '"%s" failed'
Regards:
al_shopov
[PATCH 1/1] Mark messages for translations
Reuse already translated messages if possible
Do not translate messages aimed at developers of git
Signed-off-by: Alexander Shopov <a...@kambanaria.org>
---
git.c | 30 +++---
setup.c | 52 ++--
2 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/git.c b/git.c
index c870b9719..e66316ce5 100644
--- a/git.c
+++ b/git.c
@@ -5,11 +5,11 @@
#include "run-command.h"
const char git_usage_string[] =
- "git [--version] [--help] [-C ] [-c name=value]\n"
- " [--exec-path[=]] [--html-path] [--man-path]
[--info-path]\n"
- " [-p | --paginate | --no-pager] [--no-replace-objects]
[--bare]\n"
- " [--git-dir=] [--work-tree=]
[--namespace=]\n"
- "[]";
+ N_("git [--version] [--help] [-C ] [-c name=value]\n"
+ " [--exec-path[=]] [--html-path] [--man-path]
[--info-path]\n"
+ " [-p | --paginate | --no-pager] [--no-replace-objects]
[--bare]\n"
+ " [--git-dir=] [--work-tree=]
[--namespace=]\n"
+ "[]");
const char git_more_info_string[] =
N_("'git help -a' and 'git help -g' list available subcommands and
some\n"
@@ -92,7 +92,7 @@ static int handle_options(const char ***argv, int *argc, int
*envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--git-dir")) {
if (*argc < 2) {
- fprintf(stderr, "No directory given for
--git-dir.\n" );
+ fprintf(stderr, _("No directory given for
--git-dir.\n" ));
usage(git_usage_string);
}
setenv(GIT_DIR_ENVIRONMENT, (*argv)[1], 1);
@@ -106,7 +106,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--namespace")) {
if (*argc < 2) {
- fprintf(stderr, "No namespace given for
--namespace.\n" );
+ fprintf(stderr, _("No namespace given for
--namespace.\n" ));
usage(git_usage_string);
}
setenv(GIT_NAMESPACE_ENVIRONMENT, (*argv)[1], 1);
@@ -120,7 +120,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--work-tree")) {
if (*argc < 2) {
- fprintf(stderr, "No directory given for
--work-tree.\n" );
+ fprintf(stderr, _("No directory given for
--work-tree.\n" ));
usage(git_usage_string);
}
setenv(GIT_WORK_TREE_ENVIRONMENT, (*argv)[1], 1);
@@ -134,7 +134,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--super-prefix")) {
if (*argc < 2) {
- fprintf(stderr, "No prefix given for
--super-prefix.\n" );
+ fprintf(stderr, _("No prefix given for
--super-prefix.\n" ));
usage(git_usage_string);
}
setenv(GIT_SUPER_PREFIX_ENVIRONMENT, (*argv)[1], 1);
@@ -156,7 +156,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "-c")) {
if (*argc < 2) {
- fprintf(stderr, "-c expects a configuration
string\n" );
+ fprintf(stderr, _("-c expects a configuration
string\n" ));
usage(git_usage_string);
}
git_config_push_parameter((*argv)[1]);
@@ -194,7 +194,7 @@ static int handle_options(const char ***argv, int *argc,
int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "-C")) {
if (*argc < 2) {
- fprintf(stderr, "No directory given for -C.\n"
);
+ fprintf(stderr, _("No directory given for
-C.\n" ));
usage(git_usage_string);
}
[PATCH 0/1] Marked end user messages for translation
I have marked several messages for translations in git.c and setup.c They pop from time to time on normal usage of git. The messages are aimed at end users and may help them solve issues. I have tried to keep the C formatting conventions in the two files. I have also reused messages which provides uniformity of the used verb tense and will ease the work of translators. Alexander Shopov (1): Mark messages for translations git.c | 30 +++--- setup.c | 52 ++-- 2 files changed, 41 insertions(+), 41 deletions(-) -- 2.15.1
Different merges from translation perspective
Hi all, What is the difference between simple, fast forward, automatic and trivial merge? I am updating the translation and the only thing I am sure about is that these four are not octopus merges, Fast forward is when current state is ancestor of tip, automatic merge is when the merge algorithm is decided by git rather than developer. What about simple (git-merge-octopus.sh) and trivial (builtin/merge.c)? Kind regards: al_shopov
[GIT GUI l18n 1/2] git-gui: Mark 'All' in remote.tcl for translation
Signed-off-by: Alexander Shopov <a...@kambanaria.org>
---
lib/remote.tcl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/remote.tcl b/lib/remote.tcl
index 4e5c784..26af8ae 100644
--- a/lib/remote.tcl
+++ b/lib/remote.tcl
@@ -250,12 +250,12 @@ proc update_all_remotes_menu_entry {} {
$fetch_m insert end separator
$fetch_m insert end command \
- -label "All" \
+ -label [mc "All"] \
-command fetch_from_all
$prune_m insert end separator
$prune_m insert end command \
- -label "All" \
+ -label [mc "All" ]\
-command prune_from_all
}
} else {
--
2.10.1
[PATCH] gitk: Update Bulgarian translation (311t)
Signed-off-by: Alexander Shopov <a...@kambanaria.org> --- po/bg.po | 656 --- 1 file changed, 336 insertions(+), 320 deletions(-) diff --git a/po/bg.po b/po/bg.po index 909a564..99aa77a 100644 --- a/po/bg.po +++ b/po/bg.po @@ -8,8 +8,8 @@ msgid "" msgstr "" "Project-Id-Version: gitk master\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2015-06-27 20:44+0300\n" -"PO-Revision-Date: 2015-06-27 20:46+0300\n" +"POT-Creation-Date: 2015-12-19 11:48+0200\n" +"PO-Revision-Date: 2015-12-19 11:49+0200\n" "Last-Translator: Alexander Shopov <a...@kambanaria.org>\n" "Language-Team: Bulgarian <d...@fsa-bg.org>\n" "Language: bg\n" @@ -22,11 +22,11 @@ msgstr "" msgid "Couldn't get list of unmerged files:" msgstr "Списъкът с неслети файлове не може да бъде получен:" -#: gitk:212 gitk:2381 +#: gitk:212 gitk:2399 msgid "Color words" msgstr "Оцветяване на думите" -#: gitk:217 gitk:2381 gitk:8220 gitk:8253 +#: gitk:217 gitk:2399 gitk:8239 gitk:8272 msgid "Markup words" msgstr "Отбелязване на думите" @@ -59,15 +59,15 @@ msgstr "Грешка при изпълнение на „git log“:" msgid "Reading" msgstr "Прочитане" -#: gitk:496 gitk:4525 +#: gitk:496 gitk:4544 msgid "Reading commits..." msgstr "Прочитане на подаванията…" -#: gitk:499 gitk:1637 gitk:4528 +#: gitk:499 gitk:1637 gitk:4547 msgid "No commits selected" msgstr "Не са избрани подавания" -#: gitk:1445 gitk:4045 gitk:12432 +#: gitk:1445 gitk:4064 gitk:12469 msgid "Command line" msgstr "Команден ред" @@ -79,286 +79,294 @@ msgstr "Изходът от „git log“ не може да се анализи msgid "No commit information available" msgstr "Липсва информация за подавания" -#: gitk:1903 gitk:1932 gitk:4315 gitk:9669 gitk:11241 gitk:11521 +#: gitk:1903 gitk:1932 gitk:4334 gitk:9702 gitk:11274 gitk:11554 msgid "OK" msgstr "Добре" -#: gitk:1934 gitk:4317 gitk:9196 gitk:9275 gitk:9391 gitk:9440 gitk:9671 -#: gitk:11242 gitk:11522 +#: gitk:1934 gitk:4336 gitk:9215 gitk:9294 gitk:9424 gitk:9473 gitk:9704 +#: gitk:11275 gitk:11555 msgid "Cancel" msgstr "Отказ" -#: gitk:2069 +#: gitk:2083 msgid "" -msgstr "Обновяване" +msgstr "&Обновяване" -#: gitk:2070 +#: gitk:2084 msgid "" -msgstr "Презареждане" +msgstr "&Презареждане" -#: gitk:2071 +#: gitk:2085 msgid "Reread re" -msgstr "Наново прочитане на настройките" +msgstr "&Наново прочитане на настройките" -#: gitk:2072 +#: gitk:2086 msgid " references" -msgstr "Изброяване на указателите" +msgstr "&Изброяване на указателите" -#: gitk:2074 +#: gitk:2088 msgid "Start git " -msgstr "Стартиране на „git gui“" +msgstr "&Стартиране на „git gui“" -#: gitk:2076 +#: gitk:2090 msgid "" -msgstr "Спиране на програмата" +msgstr "&Спиране на програмата" -#: gitk:2068 +#: gitk:2082 msgid "" -msgstr "Файл" +msgstr "&Файл" -#: gitk:2080 +#: gitk:2094 msgid "" -msgstr "Настройки" +msgstr "&Настройки" -#: gitk:2079 +#: gitk:2093 msgid "" -msgstr "Редактиране" +msgstr "&Редактиране" -#: gitk:2084 +#: gitk:2098 msgid " view..." -msgstr "Нов изглед…" +msgstr "&Нов изглед…" -#: gitk:2085 +#: gitk:2099 msgid " view..." -msgstr "Редактиране на изгледа…" +msgstr "&Редактиране на изгледа…" -#: gitk:2086 +#: gitk:2100 msgid " view" -msgstr "Изтриване на изгледа" +msgstr "&Изтриване на изгледа" -#: gitk:2088 gitk:4043 +#: gitk:2102 msgid " files" -msgstr "Всички файлове" +msgstr "&Всички файлове" -#: gitk:2083 gitk:4067 +#: gitk:2097 msgid "" -msgstr "Изглед" +msgstr "&Изглед" -#: gitk:2093 gitk:2103 gitk:3012 +#: gitk:2107 gitk:2117 msgid " gitk" -msgstr "Относно gitk" +msgstr "&Относно gitk" -#: gitk:2094 gitk:2108 +#: gitk:2108 gitk:2122 msgid " bindings" -msgstr "Клавишни комбинации" +msgstr "&Клавишни комбинации" -#: gitk:2092 gitk:2107 +#: gitk:2106 gitk:2121 msgid "" -msgstr "Помощ" +msgstr "Помо&щ" -#: gitk:2185 gitk:8652 +#: gitk:2199 gitk:8671 msgid "SHA1 ID:" msgstr "SHA1:" -#: gitk:2229 +#: gitk:2243 msgid "Row" msgstr "Ред" -#: gitk:2267 +#: gitk:2281 msgid "Find&q
[PATCH] gitk: Update Bulgarian translation (304t)
Signed-off-by: Alexander Shopov a...@kambanaria.org --- po/bg.po | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/po/bg.po b/po/bg.po index 1df0716..ddc8e73 100644 --- a/po/bg.po +++ b/po/bg.po @@ -1,15 +1,15 @@ # Bulgarian translation of gitk po-file. -# Copyright (C) 2014 Alexander Shopov a...@kambanaria.org. +# Copyright (C) 2014, 2015 Alexander Shopov a...@kambanaria.org. # This file is distributed under the same license as the git package. -# Alexander Shopov a...@kambanaria.org, 2014. +# Alexander Shopov a...@kambanaria.org, 2014, 2015. # # msgid msgstr Project-Id-Version: gitk master\n Report-Msgid-Bugs-To: \n -POT-Creation-Date: 2015-03-15 14:37+1100\n -PO-Revision-Date: 2014-07-28 07:32+0300\n +POT-Creation-Date: 2015-04-07 07:49+0300\n +PO-Revision-Date: 2015-04-07 07:54+0300\n Last-Translator: Alexander Shopov a...@kambanaria.org\n Language-Team: Bulgarian d...@fsa-bg.org\n Language: bg\n @@ -415,7 +415,7 @@ msgstr Right, x, l\tНапред в историята #: gitk:3053 #, tcl-format msgid %s-n\tGo to n-th parent of current commit in history list -msgstr +msgstr %s-n\tКъм n-тия родител на текущото подаване в историята #: gitk:3054 msgid PageUp\tMove up one page in commit list @@ -593,7 +593,7 @@ msgstr Грешка при изпълнението на „git blame“: %s #: gitk:3921 #, tcl-format msgid That line comes from commit %s, which is not in this view -msgstr Този ред идва от подаването %s, което не е в изгледа +msgstr Този ред идва от подаването %s, което не е в изгледа #: gitk:3935 msgid External diff viewer failed: @@ -649,12 +649,11 @@ msgstr Съобщение при подаване: #: gitk:4068 msgid Matches all Commit Info criteria -msgstr Съвпадение по коя да е информация за подаването +msgstr Съвпадение по всички характеристики на подаването #: gitk:4069 -#, fuzzy msgid Matches none Commit Info criteria -msgstr Съвпадение по коя да е информация за подаването +msgstr Съвпадение по никоя от характеристиките на подаването #: gitk:4070 msgid Changes to Files: -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [L10N] Startup of Git 2.2.0 l10n round 1
Can you please disambiguate message: msgid more than one %s It means that something somewhere was repeated but does not point what and where. Perhaps users care about that. It is now used 3 times (trailer.c:552 trailer.c:557 builtin/remote.c:288) but points to different things that were repeated. It used to mean only that there is a remote' section repeated. Kind regards: al_shopov -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixing unclear messages
- printf_ln(_(Huh (%s)?), (*ptr)-buf); + printf_ln(_(Wrong choice (%s). Choose again.), (*ptr)-buf); Why is this an improvement? Because 'Huh?' without intonation, gesture or a frown provided by a human being is hard to understand. It does not state that it is the choice the user provided is wrong and does not prompt the user for the next action. - only_include_assumed = _(Clever... amending the last one with dirty index.); + only_include_assumed = _(You are amending the last commit only. There are additional changes in the index.); Why is this an improvement? ... Besides, amending the last commit only. implies ... ... does not convey any extra information ... ...It may be time to remove these messages, by the way. ... You say that my change does not tangibly improve on an initially unclear and already obsolete message, am I right? I prefer the messages to be removed then. + die(_(fatal error in function \parse_pack_objects\. This is a bug in Git. Please report it to the developers with an e-mail to git@vger.kernel.org.)); It probably should be spelled die(BUG: ...). + die(_(fatal error in function \conclude_pack\. This is a bug in Git. Please report it to the developers with an e-mail to git@vger.kernel.org.)); Likewise. I have no stand on the issue fatal error vs BUG, if you prefer BUG I can reword. There was a suggestion to have a separate function that is meant to echo messages when there are genuine bugs in Git (impossible cases happening, invariants breaking, etc.) This will allow factoring out the clause This is a bug in Git. Please report it to the developers with an e-mail to git@vger.kernel.org. as a single message and I prefer that for ease of maintenance. + die(_(wrong format for the \in-reply-to\ header: %s), msg_id); Why is s/insane/wrong format/ an improvement? Because it is more factual and narrows down what is wrong. Insane could mean many different things. - die(_(Two output directories?)); + die(_(Maximum one output directory is allowed.)); Why is it an improvement? Because the question only implies that the problem is the number of directories but says nothing how many directories there should be (0, 1, 3... 100?) - printf(_(Wonderful.\n)); + printf(_(The first part of the trivial merge finished successfully Huh? I am not sure what you mean or your objection would be, perhaps I am misreading the source of Git. The message appears as a part of sequence during merge when the first stage passes successfully but there still could be a case that makes the whole merge impossible. What does Wonderful mean in a sequence of steps git is doing for you. You say I would buy s/something/BUG: /;, but I do not think we want to apply most of the others. Does this mean the following changes are totally unwelcome or you (plural, as corresponds to we) want me to resubmit them and substantiate changes on a message by message base? -Nope.\n +Merge was not successful.\n - ??? + unknown state -no tag message? +missing tag message -?? what are you talking about? +unknown command. Only start, good, bad and skip are possible. -Unprocessed path??? %s +The path %s was not processed but it had to be. This is a bug in Git. Please report it to the developers with an e-mail to git@vger.kernel.org. Kind regards: al_shopov -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixing unclear messages
If there were something else Huh? could mean after you give a response to that prompt, but I do not think there is. OK, you love your Huhs. Good for you. I cannot find a convincing argument then. If I were asked to say what it is then, I would say it reassures. It is like a jewel you find in a quest? On the other hand you say the message is rare enough and shown too late to be useful so there is little gain to change it. OK, fair enough. Yes, I see the primary value of this thread was to trigger that suggestion to classify which die()s are BUG()s. Wonderful. Because I've never imagined anybody would sensibly expect mv a1... ... your rewrite here is definitely a good one in that sense. My experience shows that messages need to be as helpful as possible even at the cost of some repetition. FWIW, I see it as a feature to have small number of messages phrased in colourful ways, especially the ones that do not require reaction I really do not know what to say. People can be color-blind even for messages plus in-jokes frequently do not travel well across languages. Sharing my experience: the messages were hard to translate because they were hard to understand. I had to follow the code in order to understand their meaning and usage. Hopefully other users of git will be more clever than me. I did my best at improving the messages but as you do not perceive it the same way there would be no sense in continuing the discussion much longer. Will you reconsider: - ??? + unknown state Recoding problems with translations, settings of console sometimes lead to missing or wrongly encoded characters to show as '?'. Three '?' can be confusing when shown in translation. We obviously do not want to overdo it, but the ones we have are all old ones. You overdid it for me. On the positive side I hope I have listed all oldies but goldies and next changes will be less touchy. Do you want me redoing this patch or not at all? Kind regards: al_shopov -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fixing unclear messages
Signed-off-by: Alexander Shopov a...@kambanaria.org
---
builtin/clean.c | 2 +-
builtin/commit.c | 2 +-
builtin/index-pack.c | 4 ++--
builtin/log.c| 4 ++--
builtin/merge.c | 5 +++--
builtin/remote.c | 2 +-
builtin/tag.c| 2 +-
git-bisect.sh| 2 +-
merge-recursive.c| 2 +-
9 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 1032563..9f38068 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -514,7 +514,7 @@ static int parse_choice(struct menu_stuff *menu_stuff,
if (top = 0 || bottom = 0 || top menu_stuff-nr || bottom
top ||
(is_single bottom != top)) {
clean_print_color(CLEAN_COLOR_ERROR);
- printf_ln(_(Huh (%s)?), (*ptr)-buf);
+ printf_ln(_(Wrong choice (%s). Choose again.),
(*ptr)-buf);
clean_print_color(CLEAN_COLOR_RESET);
continue;
}
diff --git a/builtin/commit.c b/builtin/commit.c
index 5ed6036..cdc8a4e 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1198,7 +1198,7 @@ static int parse_and_validate_options(int argc, const
char *argv[],
if (argc == 0 (also || (only !amend)))
die(_(No paths with --include/--only does not make sense.));
if (argc == 0 only amend)
- only_include_assumed = _(Clever... amending the last one with
dirty index.);
+ only_include_assumed = _(You are amending the last commit
only. There are additional changes in the index.);
if (argc 0 !also !only)
only_include_assumed = _(Explicit paths specified without -i
or -o; assuming --only paths...);
if (!cleanup_arg || !strcmp(cleanup_arg, default))
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 5568a5b..d9c5911 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1064,7 +1064,7 @@ static void parse_pack_objects(unsigned char *sha1)
nr_delays--;
}
if (nr_delays)
- die(_(confusion beyond insanity in parse_pack_objects()));
+ die(_(fatal error in function \parse_pack_objects\. This is
a bug in Git. Please report it to the developers with an e-mail to
git@vger.kernel.org.));
}
/*
@@ -1139,7 +1139,7 @@ static void conclude_pack(int fix_thin_pack, const char
*curr_pack, unsigned cha
int nr_unresolved = nr_deltas - nr_resolved_deltas;
int nr_objects_initial = nr_objects;
if (nr_unresolved = 0)
- die(_(confusion beyond insanity));
+ die(_(fatal error in function \conclude_pack\. This
is a bug in Git. Please report it to the developers with an e-mail to
git@vger.kernel.org.));
objects = xrealloc(objects,
(nr_objects + nr_unresolved + 1)
* sizeof(*objects));
diff --git a/builtin/log.c b/builtin/log.c
index 4389722..d614a20 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -992,7 +992,7 @@ static const char *clean_message_id(const char *msg_id)
m++;
}
if (!z)
- die(_(insane in-reply-to: %s), msg_id);
+ die(_(wrong format for the \in-reply-to\ header: %s),
msg_id);
if (++z == m)
return a;
return xmemdupz(a, z - a);
@@ -1065,7 +1065,7 @@ static int output_directory_callback(const struct option
*opt, const char *arg,
{
const char **dir = (const char **)opt-value;
if (*dir)
- die(_(Two output directories?));
+ die(_(Maximum one output directory is allowed.));
*dir = arg;
return 0;
}
diff --git a/builtin/merge.c b/builtin/merge.c
index ce82eb2..e92a74a 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -842,7 +842,8 @@ static int merge_trivial(struct commit *head, struct
commit_list *remoteheads)
struct commit_list *parents, **pptr = parents;
write_tree_trivial(result_tree);
- printf(_(Wonderful.\n));
+ printf(_(The first part of the trivial merge finished successfully
+.\n));
pptr = commit_list_append(head, pptr);
pptr = commit_list_append(remoteheads-item, pptr);
prepare_to_commit(remoteheads);
@@ -1400,7 +1401,7 @@ int cmd_merge(int argc, const char **argv, const char
*prefix)
ret = merge_trivial(head_commit, remoteheads);
goto done;
}
- printf(_(Nope.\n));
+ printf(_(Merge was not successful.\n));
}
} else {
/*
diff --git a/builtin/remote.c b/builtin/remote.c
index 9a4640d..3f480b1 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -951,7 +951,7 @@ static int show_remote_info_item(struct string_list_item
*item
Fixing WTF porcelain messages in Git
Hello everyone, I have just finished the Bulgarian translation of git. Doing this allowed me to identify about 90 places where the original messages can be improved - for consistency, spaces/tabs, abbreviations etc. 12 of these places however are really WTF messages - they do not explain properly what is wrong or right about the current state i.e. the user does not know what the problem is wrong and is left clueless how to fix things. I will send a patch with my suggestion for improving these 12 messages. Fixing these will provide most value for the final user of git. The rest of improvements can wait. I will add the maintainer of i18n, every active translator of git to CC so they can react accordingly or just add suggestions. I think fixing these in the 2.1 timeframe is not possible as the state of the translations will suffer plus there needs to be at least some minimal discussion as I can have botched the messages. I propose fixing them in early 2.1 maintenance releases or 2.2 latest. Just FYI, the set of WTFs is: #: merge-recursive.c:1861 msgid Unprocessed path??? %s #: builtin/clean.c:517 msgid Huh (%s)? #: builtin/commit.c:1201 msgid Clever... amending the last one with dirty index. #: builtin/index-pack.c:1067 msgid confusion beyond insanity in parse_pack_objects() #: builtin/index-pack.c:1142 msgid confusion beyond insanity #: builtin/log.c:995 msgid insane in-reply-to: %s #: builtin/log.c:1068 msgid Two output directories? #: builtin/merge.c:845 msgid Wonderful.\n #: builtin/merge.c:1403 msgid Nope.\n #: builtin/remote.c:954 msgid ??? #: builtin/tag.c:504 msgid no tag message? #: git-bisect.sh:424 msgid ?? what are you talking about? Kind regards: al_shopov -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fixning WTF porcelain messages
Some user-facing porcelain messages in Git are hard to understand and hard to translate. They confuse users winthout providing proper information and course of action. Here is the list of these messages (starting with -) and my suggestions (starting with +). The patch follows in the next letter. -Huh (%s)? +Wrong choice (%s). Choose again. -Clever... amending the last one with dirty index. +You are amending the last commit only. There are additional changes in the index. -confusion beyond insanity in parse_pack_objects() +fatal error in function parse_pack_objects. This is a bug in Git. Please report it to the developers with an e-mail to git@vger.kernel.org. -confusion beyond insanity +fatal error in function conclude_pack. This is a bug in Git. Please report it to the developers with an e-mail to git@vger.kernel.org. -insane in-reply-to: %s +wrong format for the in-reply-to header: %s -Two output directories? +Maximum one output directory is allowed. -Wonderful.\n +The first part of the trivial merge finished successfully.\n -Nope.\n +Merge was not successful.\n - ??? + unknown state -no tag message? +missing tag message -?? what are you talking about? +unknown command. Only start, good, bad and skip are possible. -Unprocessed path??? %s +The path %s was not processed but it had to be. This is a bug in Git. Please report it to the developers with an e-mail to git@vger.kernel.org. Alexander Shopov (1): Fixing unclear messages builtin/clean.c | 2 +- builtin/commit.c | 2 +- builtin/index-pack.c | 4 ++-- builtin/log.c| 4 ++-- builtin/merge.c | 5 +++-- builtin/remote.c | 2 +- builtin/tag.c| 2 +- git-bisect.sh| 2 +- merge-recursive.c| 2 +- 9 files changed, 13 insertions(+), 12 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Resending - Updated Bulgarian translation of git-gui
This is the updated Bulgarian translation og git-gui. It has been synced with git gitk. I have just checked the archives of the mailing list - the patch was never sent, just the previous version of the cover letter. Resending so that it can be merged for 2.1. Kind regards: al_shopov Alexander Shopov (1): git-gui i18n: Updated Bulgarian translation (520t,0f,0u) po/bg.po | 3572 +++--- 1 file changed, 1781 insertions(+), 1791 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Want to do some cleanups in this round of l10n
Or please consult https://tinyurl.com/gitcal Hello Junio, Can you put future release dates in the gitcal or is there a steady pattern like every Friday - new branch release, every Monday - stable branch release. Kind regards: al_shopov -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
