From: Enno B. <enn...@gm...> - 2013-12-23 16:36:43
|
Hello Devs, In my SVN tree I had a few patches that I didn't plan to commit, being personal hacks. In those days, I could run "svn update" and occasionaly do some manual editing to resolve merge conflicts in my local files. With GIT I checked out gramps34 as advised on the site, and copied my patches overwriting the files that I checked out. That seemed to work well for me, using "git pull" without rebase as a sort of "svn update" equivalent. A few days ago however, I discovered that there is a conflict with po/nl.po, and that git pull simply aborts on that, instead of offering a way to edit the conflict to a form that I like. Am I missing something here? thanks, Enno |
From: John R. <jr...@ce...> - 2013-12-24 00:22:59
|
On Dec 23, 2013, at 8:36 AM, Enno Borgsteede <enn...@gm...> wrote: > Hello Devs, > > In my SVN tree I had a few patches that I didn't plan to commit, being > personal hacks. In those days, I could run "svn update" and occasionaly > do some manual editing to resolve merge conflicts in my local files. > > With GIT I checked out gramps34 as advised on the site, and copied my > patches overwriting the files that I checked out. That seemed to work > well for me, using "git pull" without rebase as a sort of "svn update" > equivalent. > > A few days ago however, I discovered that there is a conflict with > po/nl.po, and that git pull simply aborts on that, instead of offering a > way to edit the conflict to a form that I like. Am I missing something here? > If you just open the file in your favorite editor, you'll find the conflicts marked with the usual <<<<<<<, =======, and >>>>>>. Fix them up the way you like, save the file and run `git add po/nl.po` to get your changes into the git index. What you do next depends on what state git is in: If it's in the middle of a merge or a rebase, say `git foo --continue` with foo standing in for either merge or rebase. There's also `git mergetool` which may or may not run a conflict resolution assistant depending on how your distro configured it. Regards, John Ralls |
From: Enno B. <enn...@gm...> - 2013-12-25 11:01:57
|
John, > If you just open the file in your favorite editor, you'll find the conflicts > marked with the usual <<<<<<<, =======, and >>>>>>. Fix them up the way you like, > save the file and run `git add po/nl.po` to get your changes into the git index. > What you do next depends on what state git is in: If it's in the middle of a merge > or a rebase, say `git foo --continue` with foo standing in for either merge or > rebase. Last time I looked at the file, I saw no such marks, and the message that my git (on Linux Mint 16) gave me suggests that it aborted the pull to prevent a conflict. Can such be the case? > There's also `git mergetool` which may or may not run a conflict resolution assistant > depending on how your distro configured it. Ah, ok, I was not aware of different configurations like that, and still feel like a beginner here. regards, Enno |
From: John R. <jr...@ce...> - 2013-12-25 17:44:13
|
On Dec 25, 2013, at 3:01 AM, Enno Borgsteede <enn...@gm...> wrote: > John, >> If you just open the file in your favorite editor, you'll find the conflicts >> marked with the usual <<<<<<<, =======, and >>>>>>. Fix them up the way you like, >> save the file and run `git add po/nl.po` to get your changes into the git index. >> What you do next depends on what state git is in: If it's in the middle of a merge >> or a rebase, say `git foo --continue` with foo standing in for either merge or >> rebase. > Last time I looked at the file, I saw no such marks, and the message that my git (on Linux Mint 16) gave me suggests that it aborted the pull to prevent a conflict. Can such be the case? It shouldn't have done unless you told it to, with git merge --abort. Otherwise, how would you fix it? It's possible that there's some other problem. Run the pull again and post the output along with the results of `git status -uno`. >> There's also `git mergetool` which may or may not run a conflict resolution assistant >> depending on how your distro configured it. > Ah, ok, I was not aware of different configurations like that, and still feel like a beginner here. Get the book: http://git-scm.com/book . Electronic versions are free. There's even a Dutch translation! Regards, John Ralls |
From: Enno B. <enn...@gm...> - 2013-12-30 12:22:49
|
OK, I ran into the problem again after Vassilii commited my GEDCOM patch to the repo. Now, when I run git pull without rebase, I see: enno@enno-desktop ~/Gramps $ git pull error: Your local changes to the following files would be overwritten by merge: src/plugins/export/ExportGedcom.py src/plugins/lib/libgedcom.py Please, commit your changes or stash them before you can merge. Aborting Status says: enno@enno-desktop ~/Gramps $ git status -uno # On branch gramps34 # Your branch and 'origin/maintenance/gramps34' have diverged, # and have 3 and 3 different commits each, respectively. # (use "git pull" to merge the remote branch into yours) # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: src/Filters/Rules/Person/_IsAncestorOf.py # modified: src/Filters/Rules/Person/_IsRelatedWith.py # modified: src/Relationship.py # modified: src/glade/editcitation.glade # modified: src/plugins/export/ExportGedcom.py # modified: src/plugins/lib/libgedcom.py # modified: src/plugins/lib/libpersonview.py # modified: src/plugins/tool/PatchNames.py # no changes added to commit (use "git add" and/or "git commit -a") Of the modified files, most are intentional, as I really want to run my personal hacks, except that the 2 GEDCOM related files should be merged. Same for an earlier local commit of o/nl.po that I did to be able to pull again after that file was changed in the repo. Now, when I check mergetool, I get: enno@enno-desktop ~/Gramps $ git mergetool This message is displayed because 'merge.tool' is not configured. See 'git mergetool --tool-help' or 'git help config' for more details. 'git mergetool' will now attempt to use one of the following tools: meld opendiff kdiff3 tkdiff xxdiff tortoisemerge gvimdiff diffuse ecmerge p4merge araxis bc3 codecompare emerge vimdiff No known merge tool is available. Which suggests that a merge would probably have been done if I had one of the tools mentioned here, but with so many available, I really have no idea what to choose. Can anyone recommend? I hope that my intentions are clear. I want to run Gramps with local hacks, without committing or pushing those to the repo, and run regular pulls like I did svn update earlier. It's that simple. thanks, Enno 2013/12/25 John Ralls <jr...@ce...> > > On Dec 25, 2013, at 3:01 AM, Enno Borgsteede <enn...@gm...> wrote: > > > John, > >> If you just open the file in your favorite editor, you'll find the > conflicts > >> marked with the usual <<<<<<<, =======, and >>>>>>. Fix them up the way > you like, > >> save the file and run `git add po/nl.po` to get your changes into the > git index. > >> What you do next depends on what state git is in: If it's in the middle > of a merge > >> or a rebase, say `git foo --continue` with foo standing in for either > merge or > >> rebase. > > Last time I looked at the file, I saw no such marks, and the message > that my git (on Linux Mint 16) gave me suggests that it aborted the pull to > prevent a conflict. Can such be the case? > > It shouldn't have done unless you told it to, with git merge --abort. > Otherwise, how would you fix it? It's possible that there's some other > problem. Run the pull again and post the output along with the results of > `git status -uno`. > > >> There's also `git mergetool` which may or may not run a conflict > resolution assistant > >> depending on how your distro configured it. > > Ah, ok, I was not aware of different configurations like that, and still > feel like a beginner here. > > Get the book: http://git-scm.com/book . Electronic versions are free. > There's even a Dutch translation! > > Regards, > John Ralls > > |
From: Nick H. <nic...@ho...> - 2013-12-30 13:28:24
|
On 30/12/13 12:22, Enno Borgsteede wrote: > I hope that my intentions are clear. I want to run Gramps with local > hacks, without committing or pushing those to the repo, and run > regular pulls like I did svn update earlier. It's that simple. Enno, You need to either commit your changes locally (but don't push them) or stash them. Probably the best thing to do would be to create a new branch for your changes. Then commit your changes locally. You should create a separate commit for each logical change. You can use 'git add' to move selected files to the staging area, and then 'git diff --cached' to review what you about to commit. This approach gives you the ability to switch between master and the branch with your changes. The master branch will diverge from your new branch, so you will want to occasionally rebase it on master. Try using meld as a merge tool. Regards, Nick. |
From: Enno B. <enn...@gm...> - 2013-12-30 21:12:16
|
Hi Nick, > Probably the best thing to do would be to create a new branch for your > changes. Then commit your changes locally. You should create a > separate commit for each logical change. Ah, that's the same answer Vassilii gave me a few weeks ago. I printed that for future reference, but it seems like I'm still missing some essential step, which is why I keep coming back with this question, and feel like running in circles now. It looks like somehow, I am not able to communicate what part of GIT I do not understand, and that quite annoys me right now, and I hope that I'm not annoying other devs in the process. Here's my take: I've used CVS in my job for years, and when I made my first steps in Gramps, it felt pretty much the same. I check out, update, merge, and when I run diff, I see where my files differ from the repo, which reassures that I'm on the right track. I see diffs for every file that is a work in progress, nowhere else, and for Gramps, every diff reflects something that I like to do different from the crowd, or something that still needs to be processed in some report, like the GEDCOM change that Vassilii pushed for me. Conceptually, this meant that my gramps34 folder was some sort of gramps34-enno branch that only existed in my mind. There was no real branch like that in SVN, but gramps34-enno existed as the sum of the central gramps34 branch and my uncommitted diffs. That was something that I understood. With GIT, I initially checked out a tracking gramps34 branch according to the instructions on the wiki, and then I put my changed files from my gramps34 SVN folder in there. That worked, as long as I used git pull, without rebase, and there were no remote changes for files that I changed here. Now, when I read your and Vassilii's advice, it looks like I have to commit my local changes to a new branch named something like gramps34-enno or whatever fancy name I choose. When I understand things right, that's where I keep my local diversions from mainstream Gramps. Sounds nice. > You can use 'git add' to move selected files to the staging area, and > then 'git diff --cached' to review what you about to commit. > > This approach gives you the ability to switch between master and the > branch with your changes. The master branch will diverge from your new > branch, so you will want to occasionally rebase it on master. OK, got that. I can imagine doing the same with gramps34 instead of master, and when local changes are committed to my gramps34-enno branch, I can rebase that gramps34 again. Sounds good, but ... ... I don't want my gramps34-enno to divert from gramps34 too much. I want to incorporate all bug fixes into my local build, and when changes are made to nl.po, I want to merge them with my local version of that too. Same when my GEDCOM patches have been pushed by Vassilii, and my local changes have become redundant. When I rebase, these changes end up in my local gramps34, but since I always build my Gramps from gramps34-enno, I need all changes merged in there! This looks like I have to do something like git checkout gramps34 git pull --rebase git checkout gramps34-enno git merge gramps34 to merge all gramps34 fixes into my personal build. Is that what I need? I'm lost, because this was easy with CVS and SVN, where gramps34-enno was just a figment of my imagination, represented by a central branch and a diff, and now it looks like this imagination needs to be materialized in branches and local commits, using a scenario that I can't find in the book. thanks for listening, Enno |
From: Nick H. <nic...@ho...> - 2013-12-30 22:29:57
|
On 30/12/13 21:12, Enno Borgsteede wrote: > ... I don't want my gramps34-enno to divert from gramps34 too much. I > want to incorporate all bug fixes into my local build, and when changes > are made to nl.po, I want to merge them with my local version of that > too. Same when my GEDCOM patches have been pushed by Vassilii, and my > local changes have become redundant. When I rebase, these changes end up > in my local gramps34, but since I always build my Gramps from > gramps34-enno, I need all changes merged in there! > > This looks like I have to do something like > > git checkout gramps34 > git pull --rebase > git checkout gramps34-enno > git merge gramps34 > > to merge all gramps34 fixes into my personal build. Is that what I need? Almost! You don't actually want to merge your changes back into gramps34. What you need to do is rebase your gramps34-enno branch onto gramps34. Instead of the merge use: git rebase gramps34 Look at the section "3.6.1 The Basic Rebase" in the Git Book. Think of the experiment branch as your gramps34-enno branch. When the branches diverge you have a situation similar to fig. 3.27 and you want to end up with fig. 3.29. By merging you ended up at fig. 3.28. Perhaps we need to document this in the wiki. Branches, local commits and rebasing are going to be new concepts for some people. I'm sure that other people will have similar questions. Let us know if you need any more help. Regards, Nick. |
From: Enno B. <enn...@gm...> - 2013-12-31 21:37:58
|
Hi Nick, > You don't actually want to merge your changes back into gramps34. What > you need to do is rebase your gramps34-enno branch onto gramps34. > > Instead of the merge use: > > git rebase gramps34 This means that I still need to commit first, right? And if that's the case, why not stick with a single gramps34 branch, i.e. no -enno or anything, and rebase that the normal way? After my commit I found that git rebase or git pull --rebase detected that the remote GEDCOM files pushed by Vassilii were the same as mine, and moved pointers or something. Is that right? > Look at the section "3.6.1 The Basic Rebase" in the Git Book. Think of > the experiment branch as your gramps34-enno branch. When the branches > diverge you have a situation similar to fig. 3.27 and you want to end up > with fig. 3.29. By merging you ended up at fig. 3.28. OK, thanks. I think I'll look into that some time next year ... > Perhaps we need to document this in the wiki. Branches, local commits > and rebasing are going to be new concepts for some people. I'm sure that > other people will have similar questions. I think so, yes, but I haven't seen those questions here, weird. > Let us know if you need any more help. Well, one thing that I haven't found yet is finding what's in my local commits. I know that I can figure out what files are in there, but sometimes I'm curious about how they diff from the remote gramps34 branch. Once I know that, I'm as close as can be to the old svn diff. thanks, Enno |
From: Nick H. <nic...@ho...> - 2014-01-01 14:27:56
|
On 31/12/13 21:37, Enno Borgsteede wrote: > This means that I still need to commit first, right? Yes. > And if that's the > case, why not stick with a single gramps34 branch, i.e. no -enno or > anything, and rebase that the normal way? You could do that, but branches are cheap in git. Keeping your local changes in a separate branch has the advantage that you still have a clean gramps34 branch to work from. > After my commit I found that git rebase or git pull --rebase detected > that the remote GEDCOM files pushed by Vassilii were the same as mine, > and moved pointers or something. Is that right? Yes. > Well, one thing that I haven't found yet is finding what's in my local > commits. git log -p > I know that I can figure out what files are in there, but > sometimes I'm curious about how they diff from the remote gramps34 > branch. Once I know that, I'm as close as can be to the old svn diff. git diff gramps34 gramps34-enno You can get help for any command by using the --help option. Nick. |
From: Vassilii K. <vas...@ta...> - 2014-01-01 20:37:44
|
On 01.01.2014 16:27, Nick Hall wrote: >> And if that's the >> >case, why not stick with a single gramps34 branch, i.e. no -enno or >> >anything, and rebase that the normal way? I do just that, when I work on a single thing within a branch, which I keep "within the context of the gramps34 branch" mentally. As soon as I need to switch to another issue, I either finish and commit and push, or, if my unpushed changes are not yet ready for the prime time, I check them in, then 0) git pull --rebase 1) create a new branch "git branch myunfinishedfix" (this leaves me on the gramps34 branch still) 2) git reset FETCH_HEAD (this resets the branch back to clean upstream gramps34 state) > You could do that, but branches are cheap in git. Keeping your local > changes in a separate branch has the advantage that you still have a > clean gramps34 branch to work from. > > |
From: Vassilii K. <vas...@ta...> - 2013-12-31 07:30:17
|
On 30.12.2013 23:12, Enno Borgsteede wrote: > when changes > are made to nl.po, I want to merge them with my local version of that > too This is something that will be pretty difficult, no matter what the underlying version control system, due to the way the .po files are generated :-( The problem is that the diff context of the .po files has things like ../gramps/foo/bar.py: 12354 ../gramps/goo/dar.py: 23536 which keeps changing, so any change to the .py files processed via the POTFILES will generate a merge conflict on the .po file which is pretty hopeless to resolve using the usual methods good for .py and other sources! What I do instead is to have a single authoritative .po at the master branch, which I then merge to other branches using "msgmerge". When I have a private dev branch tracking master, I just copy the .po file off master to it w/o any merge. When I was doing longer work --- with bug 6926 --- I had my "main" ru.po on that bug's branch, scheduling things in such a way w.r.t. the gramps release plans so that I didn't need to update the translation strings on master at all until I could merge that bug's branch. It could be that there is some know-how of doing it faster and cleaner, though --- I just haven't found out how! V. |
From: Jerome <rom...@ya...> - 2013-12-31 11:32:37
|
Hi, When I want to merge french translation, first, I want to compare files. For this, either look at sort argument on some Gnu gettext tools or the common lazy way ... Something like: $ msgfmt fr.po then # no more comments/fuzzy strings or file references + sorted entries $ msgunfmt fr.mo -o sorted_fr.po Same for the second translation file with an other name on output. To compare: $ diff -u sorted_fr.po sorted_trunk_fr.po > modified_strings.patch Second step, will be to either generate a tmp dictionary or to play with Translation Memory features (either provided by programs or simple sequence of commands!). I do not remember where is the most efficient code? I tested two/three ways! # Next, get all of the translations from other addons: for module in [name for name in os.listdir(".") if os.path.isdir(name)]: # skip the addon we are updating: if module == addon: continue po_file = r("%(module)s/po/%(locale)s-local.po", module=module) if os.path.isfile(po_file): locale_po_files.append(po_file) # Concat those together: system('''msgcat --use-first %(list)s ''' '''-o "%(addon)s/po/%(locale)s-global.po"''', list=" ".join(['''"%s"''' % name for name in locale_po_files])) # Merge the local and global: #locale_local = r("%(module)s/po/%(locale)s-local.po", module=module) #if os.path.isfile(locale_local): system('''msgmerge --no-fuzzy-matching -U "%(addon)s/po/%(locale)s-global.po" ''' '''"%(addon)s/po/%(locale)s-local.po" ''') # Get all of the addon strings out of the catalog: system('''msggrep --location=%(addon)s/* ''' '''"%(addon)s/po/%(locale)s-global.po" ''' '''--output-file="%(addon)s/po/%(locale)s-temp.po"''') # Finally, add back any updates to the local version: system('''msgcat --use-first ''' '''"%(addon)s/po/%(locale)s-temp.po" ''' '''"%(addon)s/po/%(locale)s-local.po" ''' '''-o "%(addon)s/po/%(locale)s-local.po.2" ''') system('''cp "%(addon)s/po/%(locale)s-local.po" ''' '''"%(addon)s/po/%(locale)s-local.po.1" ''') system('''cp "%(addon)s/po/%(locale)s-local.po.2" ''' '''"%(addon)s/po/%(locale)s-local.po" ''') system('''rm -v "%(addon)s/po/%(locale)s-local.po.1" ''' '''"%(addon)s/po/%(locale)s-local.po.2" ''') # # Done! http://sourceforge.net/p/gramps-addons/code/HEAD/tree/branches/gramps40/contrib/make.py def memory(arg): """ Translation memory for Gramps (own dictionary: msgid/msgstr) """ if "GRAMPSPATH" in os.environ: GRAMPSPATH = os.environ["GRAMPSPATH"] else: GRAMPSPATH = "../../../.." if not os.path.isdir(GRAMPSPATH + "/po"): raise ValueError("Where is GRAMPSPATH/po: '%s/po'? Use 'GRAMPSPATH=path python setup.py ...'" % GRAMPSPATH) # Get all of the addon strings out of the catalog os.system('''%(msggrep)s --location=../*''' ''' po/template.pot --output-file=po/%(arg)s-temp.po''' % {'msggrep': msggrepCmd, 'arg': arg} ) # start with Gramps main PO file locale_po_files = "%(GRAMPSPATH)s/po/%(arg)s.po" % {'GRAMPSPATH': GRAMPSPATH, 'arg': arg} # concat global dict as temp file if os.path.isfile(locale_po_files): print('Concat temp data: "po/%(arg)s.po" with "%(global)s".' % {'global': locale_po_files, 'arg': arg}) os.system('''%(msgcat)s --use-first po/%(arg)s.po''' ''' %(global)s -o po/%(arg)s.po --no-location''' % {'msgcat': msgcatCmd, 'global': locale_po_files, 'arg': arg} ) os.system('''%(msgcmp)s -m --use-fuzzy --use-untranslated''' ''' po/%(arg)s.po %(global)s''' % {'msgcmp': msgcmpCmd, 'global': locale_po_files , 'arg': arg} ) if os.path.isfile('po/%s-temp.po' % arg): print('Concat temp data: "po/%(arg)s.po" with "po/%(arg)s-temp.po".' % {'arg': arg}) os.system('''%(msgcat)s --use-first po/%(arg)s.po''' ''' po/%(arg)s-temp.po -o po/%(arg)s.po --no-location''' % {'msgcat': msgcatCmd, 'arg': arg} ) print('''Remove temp "po/%s-temp.po".''' % arg) os.system('''%(rm)s -rf -v po/%(arg)s-temp.po''' % {'rm': rmCmd, 'arg': arg} ) http://sourceforge.net/p/gramps-addons/code/HEAD/tree/branches/gramps40/contrib/lxml/setup.py Look at tools provided by Gnu gettext. ;) http://www.gramps-project.org/wiki/index.php?title=Translating_GRAMPS#GNU_.60gettext.27_utilities ie. msgattrib, msgcat, msgcmp, msggrep, etc ... Anyway, neither with CVS nor with SVN, I used related merging features for upgrading the french translation! I am a 'newby' on git. Regards, Jérôme Le mar. 31 déc. 2013 at 8:30,Vassilii Khachaturov <vas...@ta...> a écrit : > On 30.12.2013 23:12, Enno Borgsteede wrote: >> when changes >> are made to nl.po, I want to merge them with my local version of >> that >> too >> > This is something that will be pretty difficult, no matter what the > underlying version control system, due to the way the .po files are > generated :-( The problem is that the diff context of the .po files > has > things like > ../gramps/foo/bar.py: 12354 > ../gramps/goo/dar.py: 23536 > which keeps changing, so any change to the .py files processed via > the > POTFILES will generate a merge conflict on the .po file which is > pretty > hopeless to resolve using the usual methods good for .py and other > sources! > > What I do instead is to have a single authoritative .po at the master > branch, which I then merge to other branches using "msgmerge". When I > have a private dev branch tracking master, I just copy the .po file > off > master to it w/o any merge. When I was doing longer work --- with bug > 6926 --- I had my "main" ru.po on that bug's branch, scheduling > things > in such a way w.r.t. the gramps release plans so that I didn't need > to > update the translation strings on master at all until I could merge > that > bug's branch. > > It could be that there is some know-how of doing it faster and > cleaner, > though --- I just haven't found out how! > > V. > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most > IT > organizations don't have a clear picture of how application > performance > affects their revenue. With AppDynamics, you get 100% visibility into > your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Jerome <rom...@ya...> - 2013-12-31 14:42:07
|
Never tested, but Pology provides an environment for managing translations files (KDE projects)! "Some of the prominent elements of Pology functionality include: Examination and in-place modification of collections of PO files (the posieve command). Through unified batch-processing interface, various tools ("sieves") can be applied to messages in PO files. Format-aware diffing and patching of PO files (the poediff and poepatch commands). Line-oriented diffs/patches are rather inadequate for PO files, so Pology provides diffing and patching which specifically takes into account elements of the PO format. Handling two or more translation branches (the posummit command). When the software project has parallel or semi-parallel stable and development branches (or even more branches), "summiting" makes it possible for translators to always work on a single set of PO files, with modifications being automatically propagated to required branches. Fine-grained asynchronous review workflow (the poascribe command). Typical translation review workflow is split into stages (e.g. submit, review, approve, commit), which are handled by designated team members, and sometimes requires whole files to be reviewed at once. Pology instead provides fully asynchronous review process, where anyone can commit and review at any time, and reviews are recorded per PO message. Custom translation validation. Users can write validation rules for particular languages and projects, which can then be applied in various contexts (e.g. through posieve or posummit commands). Pology distribution contains internal validation rules for some languages and projects, and more can be contributed at any time. Language- and project-specific support. Many elements of Pology are ready to accept specific support for different languages, and different translation projects ("environments") within one language. This includes, for example, spelling dictionaries, translation validation rules, and library modules." http://www.gramps-project.org/wiki/index.php?title=Translating_GRAMPS#Pology_.28KDE.29 Le mar. 31 déc. 2013 at 12:32,Jerome <rom...@ya...> a écrit : > > Hi, > > > When I want to merge french translation, > > first, I want to compare files. > > For this, either look at sort argument on some Gnu gettext tools > or the common lazy way ... > > Something like: > > $ msgfmt fr.po > then > # no more comments/fuzzy strings or file references + sorted entries > $ msgunfmt fr.mo -o sorted_fr.po > > Same for the second translation file with an other name on output. > > To compare: > > $ diff -u sorted_fr.po sorted_trunk_fr.po > modified_strings.patch > > Second step, will be to either generate a tmp dictionary or to play > with Translation Memory features (either provided by programs or > simple > sequence of commands!). > > I do not remember where is the most efficient code? > I tested two/three ways! > > # Next, get all of the translations from other addons: > for module in [name for name in os.listdir(".") if > os.path.isdir(name)]: > # skip the addon we are updating: > if module == addon: > continue > po_file = r("%(module)s/po/%(locale)s-local.po", > module=module) > if os.path.isfile(po_file): > locale_po_files.append(po_file) > # Concat those together: > system('''msgcat --use-first %(list)s ''' > '''-o "%(addon)s/po/%(locale)s-global.po"''', > list=" ".join(['''"%s"''' % name for name in > locale_po_files])) > # Merge the local and global: > #locale_local = r("%(module)s/po/%(locale)s-local.po", > module=module) > #if os.path.isfile(locale_local): > system('''msgmerge --no-fuzzy-matching -U > "%(addon)s/po/%(locale)s-global.po" ''' > '''"%(addon)s/po/%(locale)s-local.po" ''') > > # Get all of the addon strings out of the catalog: > system('''msggrep --location=%(addon)s/* ''' > '''"%(addon)s/po/%(locale)s-global.po" ''' > > '''--output-file="%(addon)s/po/%(locale)s-temp.po"''') > # Finally, add back any updates to the local version: > system('''msgcat --use-first ''' > '''"%(addon)s/po/%(locale)s-temp.po" ''' > '''"%(addon)s/po/%(locale)s-local.po" ''' > '''-o "%(addon)s/po/%(locale)s-local.po.2" ''') > system('''cp "%(addon)s/po/%(locale)s-local.po" ''' > '''"%(addon)s/po/%(locale)s-local.po.1" ''') > system('''cp "%(addon)s/po/%(locale)s-local.po.2" ''' > '''"%(addon)s/po/%(locale)s-local.po" ''') > system('''rm -v "%(addon)s/po/%(locale)s-local.po.1" ''' > '''"%(addon)s/po/%(locale)s-local.po.2" ''') > # # Done! > > http://sourceforge.net/p/gramps-addons/code/HEAD/tree/branches/gramps40/contrib/make.py > > > def memory(arg): > """ > Translation memory for Gramps (own dictionary: msgid/msgstr) > """ > > if "GRAMPSPATH" in os.environ: > GRAMPSPATH = os.environ["GRAMPSPATH"] > else: > GRAMPSPATH = "../../../.." > > if not os.path.isdir(GRAMPSPATH + "/po"): > raise ValueError("Where is GRAMPSPATH/po: '%s/po'? Use > 'GRAMPSPATH=path python setup.py ...'" % GRAMPSPATH) > > # Get all of the addon strings out of the catalog > > os.system('''%(msggrep)s --location=../*''' > ''' po/template.pot > --output-file=po/%(arg)s-temp.po''' > % {'msggrep': msggrepCmd, 'arg': arg} > ) > > # start with Gramps main PO file > > locale_po_files = "%(GRAMPSPATH)s/po/%(arg)s.po" % > {'GRAMPSPATH': > GRAMPSPATH, 'arg': arg} > > # concat global dict as temp file > > if os.path.isfile(locale_po_files): > print('Concat temp data: "po/%(arg)s.po" with > "%(global)s".' % {'global': locale_po_files, 'arg': arg}) > > os.system('''%(msgcat)s --use-first po/%(arg)s.po''' > ''' %(global)s -o po/%(arg)s.po > --no-location''' > % {'msgcat': msgcatCmd, 'global': > locale_po_files, 'arg': arg} > ) > os.system('''%(msgcmp)s -m --use-fuzzy > --use-untranslated''' > ''' po/%(arg)s.po %(global)s''' > % {'msgcmp': msgcmpCmd, 'global': > locale_po_files , 'arg': arg} > ) > > if os.path.isfile('po/%s-temp.po' % arg): > print('Concat temp data: "po/%(arg)s.po" with > "po/%(arg)s-temp.po".' % {'arg': arg}) > > os.system('''%(msgcat)s --use-first po/%(arg)s.po''' > ''' po/%(arg)s-temp.po -o po/%(arg)s.po > --no-location''' > % {'msgcat': msgcatCmd, 'arg': arg} > ) > > print('''Remove temp "po/%s-temp.po".''' % arg) > > os.system('''%(rm)s -rf -v po/%(arg)s-temp.po''' > % {'rm': rmCmd, 'arg': arg} > ) > > http://sourceforge.net/p/gramps-addons/code/HEAD/tree/branches/gramps40/contrib/lxml/setup.py > > > Look at tools provided by Gnu gettext. ;) > http://www.gramps-project.org/wiki/index.php?title=Translating_GRAMPS#GNU_.60gettext.27_utilities > ie. msgattrib, msgcat, msgcmp, msggrep, etc ... > > Anyway, neither with CVS nor with SVN, I used related merging > features > for upgrading the french translation! I am a 'newby' on git. > > > Regards, > Jérôme > > > Le mar. 31 déc. 2013 at 8:30,Vassilii Khachaturov > <vas...@ta...> a écrit : >> On 30.12.2013 23:12, Enno Borgsteede wrote: >>> when changes >>> are made to nl.po, I want to merge them with my local version of >>> that >>> too >>> >>> >> This is something that will be pretty difficult, no matter what the >> underlying version control system, due to the way the .po files are >> generated :-( The problem is that the diff context of the .po files >> has >> things like >> ../gramps/foo/bar.py: 12354 >> ../gramps/goo/dar.py: 23536 >> which keeps changing, so any change to the .py files processed via >> the >> POTFILES will generate a merge conflict on the .po file which is >> pretty >> hopeless to resolve using the usual methods good for .py and other >> sources! >> >> What I do instead is to have a single authoritative .po at the >> master >> branch, which I then merge to other branches using "msgmerge". When >> I >> have a private dev branch tracking master, I just copy the .po file >> off >> master to it w/o any merge. When I was doing longer work --- with >> bug >> 6926 --- I had my "main" ru.po on that bug's branch, scheduling >> things >> in such a way w.r.t. the gramps release plans so that I didn't need >> to >> update the translation strings on master at all until I could merge >> that >> bug's branch. >> >> It could be that there is some know-how of doing it faster and >> cleaner, >> though --- I just haven't found out how! >> >> V. >> >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. >> Most >> IT >> organizations don't have a clear picture of how application >> performance >> affects their revenue. With AppDynamics, you get 100% visibility >> into >> your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >> AppDynamics Pro! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most > IT > organizations don't have a clear picture of how application > performance > affects their revenue. With AppDynamics, you get 100% visibility into > your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of > AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |