I made some tests with intltools, this is great. It works very well when you add your xml files to po/POTFILES.in The only cost is to suffix every xml files with ".xml", and prefix translatable xml tags with an underscore: <tooltip> becames <_tooltip> Of course we can keep compatibility with current files (no file name suffix, no tag prefix). Is it acceptable ?
2013/5/9 Éloi Rivard <[email protected]> > Some more doc: > https://developer.gnome.org/gtkmm-tutorial/3.0/sec-internationalization-intro.html.en > > > 2013/5/9 Éloi Rivard <[email protected]> > >> >> >> >> 2013/5/9 Richard Shann <[email protected]> >> >>> On Wed, 2013-05-08 at 21:24 +0200, Éloi Rivard wrote: >>> > Hi, >>> > >>> > On the po branch, make update-po now read strings directly from XML. >>> > >>> > It consists in: >>> > >>> > - Add tooltip and label as keywords (actually tags as keywords are >>> > supported) >>> >>> this is where you add options to XGETTEXT macro, right? so that xgettext >>> when run knows about those fields holding translatable strings? >>> >>> Yes, it is in the Makevars file. >> >>> > >>> > - Make extract_all generate XML_POTFILES.in >>> It still also generates commandscripts/init.scm, right? >>> but we need git rm commandscripts/not init.scm I guess? >>> >> No. XML_POTFILES only contains xml files, not scm ones. >> >>> > >>> > - Tell xgettext that actions/menu files are Glade type file. >>> This is where you have exploited the fact that telling xgettext this is >>> good enough to parse xml, right? >>> >>> Yes. >> >>> > >>> > >>> > You talked about adding some dependency to xgettext. >>> Sorry, this was a miscommunication. What I was imagining is that we >>> might get a build-dependency for Denemo on some further package called >>> glade. As I understand it, this patch is not doing that at all, it is >>> just a way of getting xgettext to extract the strings we want from our >>> xml. >>> >>> > Well, looking at the xgettext code, it seems that they support the >>> > very first versions of Glade. It xgettext keeps compatibility with old >>> > file format, one could think it won't break very soon. >>> right - that would be a slight danger, that since xgettext glade support >>> is not targetted at doing what we will be doing (parsing xml) it could >>> break. The xml support idea sounds like something xgettext people will >>> be happy to keep once it is suggested to them. >>> >>> >>> > >>> > Plus I made a feature request to generalize Glade string extraction to >>> > XML files. Maybe it will change someday ? >>> >>> yes - I think they will be happy to know that they have got more than >>> they thought (xml plus glade support) and will continue to support the >>> use of xgettext for xml files. >>> >>> I just had an answer. They say that maybe it will overlap with tools >> like intltool. >> I didn't know this tool. https://launchpad.net/intltool . It is a >> program collection specialized in data type (not code) translatable string >> extractions, like XML (and .ini, .desktop etc.) >> There some interesting things : for instance intltool-update can extract >> strings from files and set the in a .h file so that xgettext is able to >> parse it. >> Maybe it is a better idea to use this since it is a dedicated tool and >> not a xgettext hack. Plus this program has 10 years old, it might not break >> early :) >> >> > >>> > >>> > Please tell me what you think of this patch, and if I can merge >>> >>> I ran make and make dist ok on this branch, but I didn't get extract_all >>> to work - it should just happen via top level make, right? I get >>> "nothing to be done for all" doing make in the utils directory. So I am >>> not clear that this is going. >>> >> And then I don't yet have any way of testing translations. But with my >>> separate user account I should be able to safely set this up (without >>> risking turning the original strings into translated ones as happened to >>> me once on doing "Save Command Set" ...). I tried export LANG=en_GB but >>> I still got the untranslated strings running denemo after doing this. >>> >> The idea is to execute ./extract_all.sh so it can fill XML_POTFILES, and >> then go into the po directory and do make update-po But I am not very >> satisfied with it, it should be fully automated :) >> The test I did is : >> - Edit actions/menus/MainMenu/EditMenu/ConvertDrum2GmSingleSelection and >> add a dummy XML tag <tooltip>foobar</tooltip> >> - run make update-po >> - grep -RI foobar , and I saw that the string "foobar" was present in >> all po files. >> >> >> What do you think, should we keep it like this or use intltool in >> addition ? I think intltool might be the proper way. >> >>> >>> >>> Richard >>> >>> >>> > >>> > >>> > >>> > -- >>> > Éloi Rivard - [email protected] >>> > >>> > « On perd plus à être indécis qu'à se tromper. » >>> > >>> > _______________________________________________ >>> > Denemo-devel mailing list >>> > [email protected] >>> > https://lists.gnu.org/mailman/listinfo/denemo-devel >>> >>> >>> >> >> >> -- >> Éloi Rivard - [email protected] >> >> « On perd plus à être indécis qu'à se tromper. » >> > > > > -- > Éloi Rivard - [email protected] > > « On perd plus à être indécis qu'à se tromper. » > -- Éloi Rivard - [email protected] « On perd plus à être indécis qu'à se tromper. »
_______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
