Hello John,
> Intltool is *also* a dependency for most Gnome projects, so from that perspective there's no benefit to removing it as a Gramps dependency.
If I am able to get an alternative to 'intltool-extract' with few lines
of python code by using one of the XML parser provided by python, then
maybe Gramps does not really need this dependency. Should be OK for
gramps, but I wonder for gramps-connect, addons and the use of others
GUI (guiQML, etc...).
Warning, I am not saying that intltool is not useful, just that building
complete Gramps' environment (framework: code, translations maintenance,
devel) could be more 'portable' without this set of tools.
Not an advanced coding, but with simple testing:
$ intltool-extract --type=gettext/xml ../src/data/tips.xml.in
$ intltool-extract --type=gettext/xml ../src/plugins/lib/holidays.xml.in
could be replaced by something like:
from xml.etree import ElementTree
tree = ElementTree.parse(filename)
root = tree.getroot()
for key in root.getiterator(mark):
tip = ElementTree.tostring(key, encoding="UTF-8")
tip = tip.replace("<?xml version='1.0' encoding='UTF-8'?>", "")
tip = tip.replace('<_tip number="%(number)s">' % key.attrib, "")
tip = tip.replace("<br />", "<br/>")
tip = tip.replace("</_tip>\n\n", "")
print('_("%s")' % tip)
for key in root.getiterator():
if key.attrib.get(mark):
line = key.attrib
string = line.items
name = '_("%(_name)s")' % line
print(name)
where 'mark' is '_tip' or 'tip', '_name' or 'name'.
'tips.xml' is special because it also uses <br/> which sounds rather
HTML than XML. Anyway, could also use SAX (like Gramps 2.0) or DOM!
Then 'xgettext' could get these strings/messages for our
catalog/dictionary. :)
I added what I planned on 'update_po.py'!
And no port or binding: it uses the main tools (gettext, python, check_po).
Maybe some coding ways could be improved (iteration, arg[0] or for/in,
os.system(), tempfile, os, etc ...), but expected actions are grouped
and listed on this script. Is it useful? I suppose this could help most
translators!
Now, I will try to improve 'po/check_po' (a python script written for
Gramps). I looked at options, and to use '--skip-fuzzy' every time seems
more logical! eg, one 'fuzzy' string is not yet checked by human
translator, could be ignored on check process. I will try to enable this
option where it is currently missing.
Jérôme
John Ralls a écrit :
> On Mar 16, 2012, at 12:34 AM, Jérôme wrote:
>
>> Sorry, but intltool is just a set of tools, used during build time, which also requires libxml-parser-perl (Perl), automake, etc ...
>>
>> http://packages.debian.org/fr/sid/intltool
>>
>> Does, it makes sense to move out of automake and still call automake via intltool on build time? Also, I assume that Perl could be installed under Windows and Mac OS, but as this is also an extra dependency, which is not need to run Gramps, then I guess that python can parse itself its XML files too.
>
> Perl is included with OSX. Like good Unix admins everywhere, Apple uses it extensively.
> No, I don't think that it makes sense to try to use autotools from setup.py, but it's not really necessary. Generating pot files is simple enough that it can be done with a shell script.
>> Yes, to call 'gettext {DOMAIN} {STRING}' will return the expected translation for {STRING}.
>>
>> What I tried to say, was that, like under Ubuntu, if you have an OS squeleton/structure which will launch Gramps and provides specific configurations (keys, config, registering), then a simple copy of /src directory should work for having last version. eg, I run Gramps 3.3.2-SVN, without installation by overwritting 3.3.1 installation!
>> Package manager can complain about Gramps version, but I run last stable release without having to build and to use Makefile.
> Yes, that works the same on OSX. You do have to be careful about data file compatibility, but you know that.
>> You said that you need 'makefile, automake'.
>> So, as I do not have MacOS, I thought on specific issues for generating a bundle (like py2exe under Windows).
>>
>> If it is only for running './autogen.sh'.
>>
>> 1. rename 'src/const.py.in' to 'src/const.py' and set variables
>> 2. rename '/data/tips.xml.in' to '/data/tips.xml' (you can also remove translation sign/mark on attributes and tags)
>> 3. rename 'plugins/lib/holidays.xml.in' to 'plugins/lib/holidays.xml'
>
> That's done with simple substitution, so we could write a short python program to do the same thing that configure does if necessary, but doesn't distutils already have a facility for customizing installation paths?
>
>> OS issue. look at man, keys, mime, desktop files generated by previous installation (Makefile), and use copies # under Linux
>
> OSX doesn't care about any of that stuff.
>
>> I have no idea if one Gramps' translator is using MacOS.
>> If there is one, then how can he/she update translation according last template? Same question under Windows OS!
>>
>> If translator is able to run 'check_po':
>> http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/check_po
>> Then translator should be able to run 'update_po.py' too:
>> http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/po/update_po.py
>>
>> I looked at mac and windows directories under SVN and I did not find any answer about the use of gettext (or commands) under MacOS.
>> I assume, as UNIX-like, it is like under Linux.
> Nothing "UNIX-like" about it. It's FreeBSD Unix on top of a Mach microkernel.
>> ex: os.system('''%(command)s %(domain)s %(strings)s'''
>> '''% {'command': 'gettext', 'domain': gramps, 'string': 'Family Trees'})
>>
>> or whatever command and options.
>>
>> I am currently grouping used commands by translators into one python script, with basic code for handling these variables.
>>
>> elif sys.platform == 'linux2':
>> msgmergeCmd = 'msgmerge'
>> msgfmtCmd = 'msgfmt'
>> pythonCmd = 'python'
>>
>> os.system('''%(program)s -V''' % {'program': msgmergeCmd})
>>
>> os.system('''xgettext --add-comments -j -o gramps.pot '''
>> '''--keyword=N_ --from-code=UTF-8 %(head)s''' % {'head': h}
>>
>> os.system('''rm %s''' % h)
>>
>> os.system('''%(msgmerge)s --no-wrap %(lang)s gramps.pot -o
>> updated_%(lang)s''' % {'msgmerge': msgmergeCmd, 'lang': arg})
>>
>> os.system('''%(python)s ./check_po ./%(lang.po)s > %(lang)s.txt''' \
>> % {'python': pythonCmd, 'lang.po': arg, 'lang': arg[:2]})
>>
>> 'xgettext' and 'rm' will be also variables.
>>
>> As I do not run MacOS, do 'xgettext', 'rm', 'python' commands will run as expected with the use of 'os.system()' ?
>
> Yup, though xgettext isn't provided by OSX, as I noted earlier in the thread.
> Rather than incurring the overhead for a bunch of os.system() calls, I'd write a shell script and call that from os.system().
> But isn't there already a python tool for doing this?
>>
>>
>> John,
>>
>>> Intltool is *also* a dependency for most Gnome projects, so from that perspective there's no benefit to removing it as a Gramps dependency.
>> OK, no benefit for building under MacOS.
>> That was my expected type of answer. Thank you!
>>
>> But there is one benefit: less Gnome dependency ...
> Pointless until someone writes a new UI. (I'd love to do a PyObjC UI for Gramps. I don't see ever having the time.)
>>> If you think that there are potential Gramps translators out there looking for a Mac-based tool to use, you could talk to the developers of some Gtk tools and get them to do a Mac port with Gtk-OSX...
>>> (Haven't we had this discussion before?)
>> I do not think so ?
>>
>> In fact, there is already some tools for translating gettext files under MacOS.
>> http://www.gramps-project.org/wiki/index.php?title=Translating_GRAMPS#Translating_messages
>> Oops, there is no MacOS reference on this page, isn't it?
>>
>> Virtaal, Poedit are providing MacOs versions
>> http://translate.sourceforge.net/wiki/virtaal/index
>> http://www.poedit.net/download.php
>> and every text editors, compliant with UTF-8 should be also able to help to do translation.
>
> Cool. No worries, then.
>
>> The problem is somewhere else.
>> Every time there is a minor change on a string noted for been translated, then the template (gramps.pot) is outdated and translators need to merge their current translations with an updated template.
>>
>> This was always done with command line and this is also one of the big problem for centralized translations managers.
>> Translators have to follow some rules:
>> http://www.gramps-project.org/wiki/index.php?title=Translating_GRAMPS#Getting_started
>> and Gramps allows to use some powerful tools (existing or specific):
>> http://www.gramps-project.org/wiki/index.php?title=Translating_GRAMPS#Testing_your_.po_file
>>
>> All of this stuff, could be grouped and handled with a CLI tool, which runs under python. ie. above experimental use of os.system and commands.
>>
>> If you look at translations, there is some 'fatal' errors.
>> I will try to fix them but it will be great if I/we could save some time for checking them and for updating some of them ...
>> http://www.gramps-project.org/wiki/index.php?title=GRAMPS_translations
>
> Gnucash handles translation by generating a new potfile a few weeks before a major release, committing it to SVN, declaring a string freeze, and notifying the translation project and independent translators. SVN takes care of merging the potfile changes. Doesn't Gramps do more or less the same thing? That makes generating the potfile a developer responsibility, and aside from the M$Win and mac maintainers, all the devs are using Linux, aren't they? Seems you're worrying needlessly.
>
> Regards,
> John Ralls
>
>
>
|