2012/10/2 jerome <romjerome@yahoo.fr>
> "Alternatively, I could keep the Makefiles for po generation."

It seems that current translation environment (POTFILES.in POTFILE.skip, Makefile.am) is related to configure.in!
Inherited from Gnome...



An illustration could be the "unittest for testing POTFILES.in and Makefile contents":

'configure/Makefile' are related, and to only provide Makefile for po generation will maybe mean to keep 'configure/makefile' framework for all gramps' modules!

Note, the 'po/test/po_test.py' script was for testing missing references into Makefile.am or POTFILES.in and POTFILE.skip. To keep Makefiles mean to still deal with these possible missing references!!!

I defenitely don't want to update anymore Makefile.in
However, to update POTFILES would be possible...
I'll look at it when finished with the import problems.



--- En date de : Mar 2.10.12, Benny Malengier <benny.malengier@gmail.com> a écrit :

De: Benny Malengier <benny.malengier@gmail.com>
Objet: Re: Re : po
À: "jerome" <romjerome@yahoo.fr>
Cc: "Gramps Development List" <gramps-devel@lists.sourceforge.net>
Date: Mardi 2 octobre 2012, 10h28

Alternatively, I could keep the Makefiles for po generation.
People installing Gramps don't need to run make, but you would have to do it in the po directory.


2012/10/2 jerome <romjerome@yahoo.fr>


It is still experimental for handling po files and gramps.pot with python libs and GNU tools only.

In fact, it was tested with python 2.6 some months ago...

One thing is remaining for a complete support with python 2.7: one "function/set of lines" is still working with python 2.6 only.

Something like:

from xml.etree import ElementTree

    tree = ElementTree.parse(filename)

    root = tree.getroot()

    mark = _tip

    for key in root.getiterator(mark):

I tested an other way, which seems to be more correct, something like:

    for key in root.iter():

        if key.attrib.get(mark):


To spare one line does not really makes sense if this does not work after a python update/migration... I suppose it could be one common function for both files who really need to be parsed: 'holidays.xml' and 'tips.xml'.

Note, 'optparse' is also a deprecated module under python 2.7 (migration)... http://docs.python.org/library/optparse.html

I know that it should rather use 'argparse' with this python version.


> Second, if you test on python version, don't check on the 7, but use instead > or <.

Currently, it should still work with python 2.6 and there is a partial support with python 2.7. About python 3.x, I do not think this will work!

Yes, the next step will be to support python 2.7 and +.

If so, do not need to test for python 2.6 anymore.

Note, about translation and 'src->gramps' migration, one module usage is not clear, but I guess it will be modified on next revisions: 'const.py.in'. It is cosmetic. ie. to change 'const.py.in' reference by 'const.py'. Else, 'update_po' has grouped all commands/steps for translation/template handling by using python.

John and Rob did not think that getting rid of 'intltool' was useful.

If Gramps provides a more 'python-standard' way for installation, I suppose to have a python script for translations might be also useful.

It could be also used under others pateforms with few efforts.

Thank you for advices about coding.


--- En date de : Lun 1.10.12, Benny Malengier <benny.malengier@gmail.com> a écrit :

De: Benny Malengier <benny.malengier@gmail.com>

Objet: po

À: "Jérôme" <romjerome@yahoo.fr>

Cc: "Gramps Development List" <gramps-devel@lists.sourceforge.net>

Date: Lundi 1 octobre 2012, 19h30


I see you changed update_po. Some things.

First, trunk requires python 2.7, so it is not needed to do python 2.6 workarounds.

Second, if you test on python version, don't check on the 7, but use instead > or <.