Update Swedish translation. by nafmo · Pull Request #1 · avar/git

nafmo · 2011-08-19T10:22:38Z

Hi!

I finally got around to update the Swedish translation, as per your request in July. Due to various personal reasons - one of which documented at http://www.softwolves.pp.se/blog/2011-07-04 - it took a bit longer than necessary, sorry about that.

// Peter

Translate some non-TEST into Icelandic. This is far from a complete translation, I've only translated init-db.c. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

An incomplete German translation. Signed-off-by: Jan Krüger <jk@jk.gs> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

Translate three Git messages from US to British English. These all had to do with z v.s. s differences. Signed-off-by: Sam Reed <sam@reedyboy.net> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

Translate a few Git messages to Standard Hindi. It uses a phonetic script called Devanagari. Focus especially on transforming grammar and tense in a sane manner to serve as a guideline for future translators. Note that Devanagari rendering is broken on many applications by default at this time- the latest Emacs, Vim and Chrome render it incorrectly. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Acked-by: Antriksh Pany <antriksh.pany@gmail.com> Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

An incomplete Polish translation. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Marcin Cieślak <saper@saper.info>

Signed-off-by: Peter Krefting <peter@softwolves.pp.se> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

Translate all 689 currently translatable messages in Git into German. Making the German translation 100% complete. [Ævar Arnfjörð Bjarmason: Modified by running msgmerge(1) on it to normalize the line wrapping, and squashed two of Jan's commits together] Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

Also incorporate review changes from the first translation run by Göran Uddeborg <goeran@uddeborg.se> Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

avar · 2011-08-19T12:18:21Z

Np, will try to submin it soon
On Aug 19, 2011 10:22 AM, "nafmo" <
reply@reply.github.com>
wrote:

Hi!

I finally got around to update the Swedish translation, as per your
request in July. Due to various personal reasons - one of which documented
at http://www.softwolves.pp.se/blog/2011-07-04 - it took a bit longer than
necessary, sorry about that.

// Peter

Reply to this email directly or view it on GitHub:
#1

The previous logic in show_config was to print the delimiter when the value was set, but Boolean variables have an implicit value "true" when they appear with no value in the config file. As a result, we got: git_Config --get-regexp '.*\.Boolean' #1. Ok: example.boolean git_Config --bool --get-regexp '.*\.Boolean' #2. NO: example.booleantrue Fix this by defering the display of the separator until after the value to display has been computed. Reported-by: Brian Foster <brian.foster@maxim-ic.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>

While identifying the commit merged to our history as "parent #2" is technically correct, we will never say "parent #1" (as that is the tip of our history before the merge is made), and we rarely would say "parent #3" (which would mean the merge is an octopus), especially when responding to a request to pull a signed tag. Treat the most common case to merge a single commit specially, and just say "merged tag '<tagname>'" instead. Signed-off-by: Junio C Hamano <gitster@pobox.com>

entry_count is used in update_one() for two purposes: 1. to skip through the number of processed entries in in-memory index 2. to record the number of entries this cache-tree covers on disk Unfortunately when CE_REMOVE is present these numbers are not the same because CE_REMOVE entries are automatically removed before writing to disk but entry_count is not adjusted and still counts CE_REMOVE entries. Separate the two use cases into two different variables. #1 is taken care by the new field count in struct cache_tree_sub and entry_count is prepared for #2. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

The DWIM mode of checkout allows you to run "git checkout foo" when there is no existing local ref or path called "foo", and there is exactly _one_ remote with a remote-tracking branch called "foo". Git will automatically create a new local branch called "foo" using the remote-tracking "foo" as its starting point and configured upstream. For example, consider the following unconventional (but perfectly valid) remote setup: [remote "origin"] fetch = refs/heads/*:refs/remotes/origin/* [remote "frotz"] fetch = refs/heads/*:refs/remotes/frotz/nitfol/* Case 1: Assume both "origin" and "frotz" have remote-tracking branches called "foo", at "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo" respectively. In this case "git checkout foo" should fail, because there is more than one remote with a "foo" branch. Case 2: Assume only "frotz" have a remote-tracking branch called "foo". In this case "git checkout foo" should succeed, and create a local branch "foo" from "refs/remotes/frotz/nitfol/foo", using remote branch "foo" from "frotz" as its upstream. The current code hardcodes the assumption that all remote-tracking branches must match the "refs/remotes/$remote/*" pattern (which is true for remotes with "conventional" refspecs, but not true for the "frotz" remote above). When running "git checkout foo", the current code looks for exactly one ref matching "refs/remotes/*/foo", hence in the above example, it fails to find "refs/remotes/frotz/nitfol/foo", which causes it to fail both case #1 and #2. The better way to handle the above example is to actually study the fetch refspecs to deduce the candidate remote-tracking branches for "foo"; i.e. assume "foo" is a remote branch being fetched, and then map "refs/heads/foo" through the refspecs in order to get the corresponding remote-tracking branches "refs/remotes/origin/foo" and "refs/remotes/frotz/nitfol/foo". Finally we check which of these happens to exist in the local repo, and if there is exactly one, we have an unambiguous match for "git checkout foo", and may proceed. This fixes most of the failing tests introduced in the previous patch. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>

We have two ways of dealing with empty pathspec: 1. limit it to current prefix 2. match the entire working directory Some commands go with #1, some #2. get_pathspec() and parse_pathspec() only support #1. Make parse_pathspec() reject empty pathspec by default. #1 and #2 can be specified via new flags. This makes it more expressive about default behavior at command level. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of refs/remotes/*), we changed the rules for what is considered a valid tracking branch (a.k.a. upstream branch). We now use the configured remotes and their refspecs to determine whether a proposed tracking branch is in fact within the domain of a remote, and we then use that information to deduce the upstream configuration (branch.<name>.remote and branch.<name>.merge). However, with that change, we also check that - in addition to a matching refspec - the result of mapping the tracking branch through that refspec (i.e. the corresponding ref name in the remote repo) happens to start with "refs/heads/". In other words, we require that a tracking branch refers to a _branch_ in the remote repo. Now, consider that you are e.g. setting up an automated building/testing infrastructure for a group of similar "source" repositories. The build/test infrastructure consists of a central scheduler, and a number of build/test "slave" machines that perform the actual build/test work. The scheduler monitors the group of similar repos for changes (e.g. with a periodic "git fetch"), and triggers builds/tests to be run on one or more slaves. Graphically the changes flow between the repos like this: Source #1 -------v ----> Slave #1 / Source #2 -----> Scheduler -----> Slave #2 \ Source #3 -------^ ----> Slave #3 ... ... The scheduler maintains a single Git repo with each of the source repos set up as distinct remotes. The slaves also need access to all the changes from all of the source repos, so they pull from the scheduler repo, but using the following custom refspec: remote.origin.fetch = "+refs/remotes/*:refs/remotes/*" This makes all of the scheduler's remote-tracking branches automatically available as identical remote-tracking branches in each of the slaves. Now, consider what happens if a slave tries to create a local branch with one of the remote-tracking branches as upstream: git branch local_branch --track refs/remotes/source-1/some_branch Git now looks at the configured remotes (in this case there is only "origin", pointing to the scheduler's repo) and sees refs/remotes/source-1/some_branch matching origin's refspec. Mapping through that refspec we find that the corresponding remote ref name is "refs/remotes/source-1/some_branch". However, since this remote ref name does not start with "refs/heads/", we discard it as a suitable upstream, and the whole command fails. This patch adds a testcase demonstrating this failure by creating two source repos ("a" and "b") that are forwarded through a scheduler ("c") to a slave repo ("d"), that then tries create a local branch with an upstream. See the next patch in this series for the exciting conclusion to this story... Reported-by: Per Cederqvist <cederp@opera.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>

When ac49f5c (rerere "remaining", 2011-02-16) split out a new helper function check_one_conflict() out of find_conflict() function, so that the latter will use the returned value from the new helper to update the loop control variable that is an index into active_cache[], the new variable incremented the index by one too many when it found a path with only stage #1 entry at the very end of active_cache[]. This "strange" return value does not have any effect on the loop control of two callers of this function, as they all notice that active_nr+2 is larger than active_nr just like active_nr+1 is, but nevertheless it puzzles the readers when they are trying to figure out what the function is trying to do. In fact, there is no need to do an early return. The code that follows after skipping the stage #1 entry is fully prepared to handle a case where the entry is at the very end of active_cache[]. Help future readers from unnecessary confusion by dropping an early return. We skip the stage #1 entry, and if there are stage #2 and stage #3 entries for the same path, we diagnose the path as THREE_STAGED (otherwise we say PUNTED), and then we skip all entries for the same path. Signed-off-by: Junio C Hamano <gitster@pobox.com>

A conflicted index can have multiple stage #1 entries when dealing with a criss-cross merge and using the "resolve" merge strategy. Signed-off-by: Junio C Hamano <gitster@pobox.com>

A conflicted index can have multiple stage #1 entries when dealing with a criss-cross merge and using the "resolve" merge strategy. Plug the leak by reading only the first one of the same stage entries. Strictly speaking, this fix does change the semantics, in that we used to use the last stage #1 entry as the common ancestor when doing the plain-vanilla three-way merge, but with the leak fix, we will use the first stage #1 entry. But it is not a grave backward compatibility breakage. Either way, we are arbitrarily picking one of multiple stage #1 entries and using it, ignoring others, and there is no meaning in the ordering of these stage #1 entries. Signed-off-by: Junio C Hamano <gitster@pobox.com>

Code clean-up and minor fixes. * jc/rerere: (21 commits) rerere: un-nest merge() further rerere: use "struct rerere_id" instead of "char *" for conflict ID rerere: call conflict-ids IDs rerere: further clarify do_rerere_one_path() rerere: further de-dent do_plain_rerere() rerere: refactor "replay" part of do_plain_rerere() rerere: explain the remainder rerere: explain "rerere forget" codepath rerere: explain the primary codepath rerere: explain MERGE_RR management helpers rerere: fix benign off-by-one non-bug and clarify code rerere: explain the rerere I/O abstraction rerere: do not leak mmfile[] for a path with multiple stage #1 entries rerere: stop looping unnecessarily rerere: drop want_sp parameter from is_cmarker() rerere: report autoupdated paths only after actually updating them rerere: write out each record of MERGE_RR in one go rerere: lift PATH_MAX limitation rerere: plug conflict ID leaks rerere: handle conflicts with multiple stage #1 entries ...

We generate the squash commit message incrementally running a sed script once for each commit. It parses "This is a combination of <N> commits" from the first line of the existing message, adds one to <N>, and uses the result as the number of our current message. Since f2d1706 (i18n: rebase-interactive: mark comments of squash for translation, 2016-06-17), the first line may be localized, and sed uses a pretty liberal regex, looking for: /^#.*([0-9][0-9]*)/ The "[0-9][0-9]*" tries to match double digits, but it doesn't quite work. The first ".*" is greedy, so if you have: This is a combination of 10 commits. it will eat up "This is a combination of 1", leaving "0" to match the first "[0-9]" digit, and then skipping the optional match of "[0-9]*". As a result, the count resets every 10 commits, and a 15-commit squash would end up as: # This is a combination of 5 commits. # This is the 1st commit message: ... # This is the commit message #2: ... and so on .. # This is the commit message git#10: ... # This is the commit message #1: ... # This is the commit message #2: ... etc, up to 5 ... We can fix this by making the ".*" less greedy. Instead of depending on ".*?" working portably, we can just limit the match to non-digit characters, which accomplishes the same thing. Reported-by: Brandon Tolsch <btolsch@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Amend my change earlier in this series ("grep: add support for the PCRE v1 JIT API", 2017-04-11) to un-break the build on PCRE v1 versions later than 8.31 compiled without --enable-jit. As explained in that change and a later compatibility change in this series ("grep: un-break building with PCRE < 8.32", 2017-05-10) the pcre_jit_exec() function is a faster path to execute the JIT. Unfortunately there's no compatibility stub for that function compiled into the library if pcre_config(PCRE_CONFIG_JIT, &ret) would return 0, and no macro that can be used to check for it, so the only portable option to support builds without --enable-jit is via a new NO_LIBPCRE1_JIT=UnfortunatelyYes Makefile option[1]. Another option would be to make the JIT opt-in via USE_LIBPCRE1_JIT=YesPlease, after all it's not a default option of PCRE v1. I think it makes more sense to make it opt-out since even though it's not a default option, most packagers of PCRE seem to turn it on by default, with the notable exception of the MinGW package. Make the MinGW platform work by default by changing the build defaults to turn on NO_LIBPCRE1_JIT=UnfortunatelyYes. It is the only platform that turns on USE_LIBPCRE=YesPlease by default, see commit df5218b ("config.mak.uname: support MSys2", 2016-01-13) for that change. 1. "How do I support pcre1 JIT on all versions?" (https://lists.exim.org/lurker/thread/20170601.103148.10253788.en.html) 2. https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-pcre/PKGBUILD (referenced from "Re: PCRE v2 compile error, was Re: What's cooking in git.git (May 2017, #1; Mon, 1)"; <alpine.DEB.2.20.1705021756530.3480@virtualbox>) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

avar and others added 15 commits July 6, 2011 19:18

po/is.po: add Icelandic translation

37bfc8d

Translate some non-TEST into Icelandic. This is far from a complete translation, I've only translated init-db.c. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

po/de.po: add German translation

d110c09

An incomplete German translation. Signed-off-by: Jan Krüger <jk@jk.gs> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

po/en_GB.po: add British English translation

f33d8f8

Translate three Git messages from US to British English. These all had to do with z v.s. s differences. Signed-off-by: Sam Reed <sam@reedyboy.net> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

po/pl.po: add Polish translation

6f312e3

An incomplete Polish translation. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Marcin Cieślak <saper@saper.info>

po/sv.po: add Swedish translation

5c8a006

Signed-off-by: Peter Krefting <peter@softwolves.pp.se> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>

de.po: msgmerge

c248a8f

en_GB.po: msgmerge

938237c

hi.po: msgmerge

c61d738

is.po: msgmerge

a073e3c

pl.po: msgmerge

9f01805

sv.po: msgmerge

c5d2a3c

en_GB is OK now

ceb5833

Update Swedish translation (701t0f0u).

0a655b9

Also incorporate review changes from the first translation run by Göran Uddeborg <goeran@uddeborg.se> Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

nafmo closed this Mar 8, 2012

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2010/10 #1)

9c62365

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2010/11 #1)

f523a49

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2010/12 #1)

8f05eee

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2011/01 #1)

bcbd9dd

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2011/02 #1)

d191614

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2011/03 #1)

ce29fc8

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2011/04 #1)

f0ee024

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2011/05 #1)

ed35c5e

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2011/06 #1)

44ca61b

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2011/07 #1)

ebfa00b

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2011/08 #1)

5fe51da

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2011/09 #1)

65ef6cb

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2001/10 #1)

4361d41

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2011/11 #1)

d14d04c

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2012/01 #1)

beb65c4

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2012/02 #1)

f37cba2

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2012/03 #1)

f0339e0

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2012/04 #1)

dd5c59e

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2012/05 #1)

81fb448

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2012/06 #1)

5321cb2

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2012/07 #1)

82f5aa1

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2012/08 #1)

b3d7cea

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2012/09 #1)

e911aec

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2012/10 #1)

d6f2734

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2012/11 #1)

3a0d924

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2012/12 #1)

06815c0

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2013/01 #1)

54f4a1f

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2013/02 #1)

8a7f1ba

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2013/03 #1)

0887fb7

avar pushed a commit that referenced this pull request Dec 1, 2020

What's cooking (2013/04 #1)

5f3c2ea

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update Swedish translation.#1

Update Swedish translation.#1
nafmo wants to merge 15 commits intoavar:ab/i18n-pofrom
nafmo:pk/update-sv

nafmo commented Aug 19, 2011

Uh oh!

avar commented Aug 19, 2011

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Conversation

nafmo commented Aug 19, 2011

Uh oh!

avar commented Aug 19, 2011

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants