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
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
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
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
- 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
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
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
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
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,
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 @
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
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
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 chang
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
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-igno
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
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 !
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
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
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
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
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
22 matches
Mail list logo