openerp-expert-localization team mailing list archive

["P. Christeas" <p_christ@xxxxxx>]

On Friday 29 October 2010, Ferdinand Gassauer wrote:
> On Friday 29 October 2010 P. Christeas wrote:
> > Given the serious disadvantages of Launchpad for translations, I have
> > spent a couple of hours testing an alternative: Transifex.
> 
> what I have done ...

I did another experiment today (well, nothing new, this process is my "old" 
one) and recorded the procedure.

The key concept is that we don't have any reason to use Launchpad. The 
translations have always been kept inside the code, so downloading/uploading 
to Launchpad is just an unnecessary step.

What I wanted to prove here is that a non-linear translation procedure can 
really work.

But, in order to have that, there *must be* a final maintainer, a human, that 
will resolve the conflicts and "clean" the final translations. IMHO, this is 
much better than letting the LP scripts decide which string to use, solely 
based on the "who comes last, wins" principle.

Combine the repo-based translation with that old script which symlinks the .po 
files into one folder, and your favourite .po editor (eg. lokalize), and you 
get a very efficient translation workflow.

Note also that the translator will not necessarily have to work on a working 
repository. Just as long as she/he can get the bunch of po files from the 
maintainer and send the results back (with email), can work, too.

Dr. Gassauer, you are right about the OpenERP module. This will be my next 
experiment, to see if, at the end of the day, OpenERP itself _is_ the best 
tool for translations.


-- 
Say NO to spam and viruses. Stop using Microsoft Windows!

I locate the point where the translation process had been based on.
This must be the 24 Oct Launchpad sync: 23a773714ab2b27e1a

    $ git checkout -b chricar-trans 23a773714ab2b27e1a

I move Dr. Gassauer's translations from his tarball to the git folder:

    $ for PODIR in * ; do 
	if [ -f "$PODIR/i18n/$PODIR-de.po" ] ; then 
	    mv -f "$PODIR/i18n/$PODIR-de.po" "$OLDPWD/$PODIR/i18n/de.po"
	fi
    done

I commit the changes, quoting the original author and message from the
email:
    $ git commit -a --author="Ferdinand Gassauer..."
    ...
    $ git show 01f4b1cfc112614b34

I merge the official trunk head. Git is "trained" to do all the rest,
automatically. However, in this very case, it comes up with a real
conflict:
    $ git merge 3f0bd12dab24554a4
    Removing account_reporting/account_report.xml
    Removing membership/demo_data.xml
    CONFLICT (delete/modify): partner_geo_assign/i18n/de.po deleted in 3f0bd12dab24554a4 and modified in HEAD. Version HEAD of partner_geo_assign/i18n/de.po left in tree.
    Removing partner_geo_assign/i18n/fr.po
    Removing partner_geo_assign/i18n/it.po
    Removing share/security/ir.model.access.csv
    Automatic merge failed; fix conflicts and then commit the result.

For that, I inspect the diff of 01f4b1cfc112614b34, and realize that Dr. Gassauer
had only translated strings that are common to all modules, in "partner_geo_assing".
So, I decide that it is safe to delete, since no work will be actually lost.

    $ git mergetool
    Merging the files: partner_geo_assign/i18n/de.po

    Deleted merge conflict for 'partner_geo_assign/i18n/de.po':
    {local}: modified
    {remote}: deleted
    Use (m)odified or (d)eleted file, or (a)bort? d
    $

I inspect the result:
    $ git diff 3f0bd12dab24554a4..HEAD */i18n/de.po

I then realize that it was a 2-way merge, not a 3-way, since no term in German
had changed from 23a773714ab2b27e1a to the trunk 3f0bd12dab24554a4 head.

Let us repeat that non-linearly:

I go to the official trunk and translate sth in German:
    $ git checkout -b non-lin-trans 3f0bd12dab24554a4
    $ lokalize procurement/i18n/de.po
    $ git diff

I commit, and then I merge with the translation of Dr Gassauer:
    $ git commit -a
    $ git merge chricar-trans

Without the po-scripts, I would get a merge conflict, which I would have
to resolve with mergetool (only works for a few strings).
But, with the po-scripts, the process is automatic:
    $ less procurement/i18n/de.po
    ...
    #. module: procurement
    #: field:procurement.order,name:0 view:procurement.order:0
    #, fuzzy
    msgid "Reason"
    msgstr ""
    "#-#-#-#-#  .merge_file_3gmGSH (openobject-addons)  #-#-#-#-#\n"
    "Grund\n"
    "#-#-#-#-#  .merge_file_cn5lIq (openobject-addons)  #-#-#-#-#\n"
    "Begründung"

.. which means that the two translations would be visible to the final
language maintainer.