Integration with babel?

[gforcada]

Seems that on the wider python ecosystem other i18n tools are used and developed. One of them is Babel, which most probably is not a 1:1 replacement for i18ndude, but maybe we can leverage it so that we can benefit from its wider community and (maybe) better tools.

Babel itself is extensible, so we could analyze i18ndude functionality, rip apart what's already provided by Babel from i18ndude and turn the rest (I guess mostly template and XML extraction) into Babel plugins.

That probably will lower the barrier of complexity that i18ndude (the specific parts still needed) puts into getting more contributors and improving it in general.

Did anyone else took a look at it?

[rnixx]

Hi, I use lingua (https://github.com/wichert/lingua) for a while now and I'm quite happy with it. It already integrates Babel, provides all sorts of useful plugins for Zope/Plone/Pyramid development and is easy to extend (e.g. a plugin for YAFOWIL https://github.com/bluedynamics/yafowil.lingua). Less important, but finally it works with Python 3.

[jensens]

I would also propose to switch to lingua.

[vincentfretin]

For Pyramid projects, I only use lingua and its pot-create command and standard msgmerge command from gettext.

[rnixx]

@vincentfretin I'm also not using anything from Babel, but since it was subject to this issue I mentioned it. lingua OOTB should be enough normally.

[gforcada]

Oh, I see, even better then! So is there a reason to stick with i18ndude? That's what we are still suggesting on bobtemplates.plone and referenced as well on docs.plone.org

[rnixx]

@gforcada IMHO there's no reason. i18ndude should get a monument for it's services and we should move forward ;)

[jensens]

at some point lingua had problems handling multiple i18ndomains in one run. but maybe this was solved meanwhile. I'am not very uptodate with my knowledge here.

[wichert]

@jensens What kind of problems are you referring to? As far as I know that has worked correctly for quite some time. The only thing that comes to mind is the ability to select which domain to extract from a template, which was added in Lingua 2.0 (released April 8, 2014).

[jensens]

@wichert thanks, indeed, this was before 2.0 release, so no objections left from my side.

[vincentfretin]

Tell me if I'm wrong, but I think lingua doesn't support extracting messages from GenericSetup profiles.
Does lingua supports the non standard way of specifying msgid in i18n:translate and default message as a comment in the po file? I'm not sure.
I know latest version of lingua/translationstring/chameleon implements i18n:context and generate standard msgctx in the po file.

[vincentfretin]

msgmerge doesn't support the non standard po (default message in a comment), so we still need i18ndude code to merge po files from pot file.

[rnixx]

@vincentfretin I cannot tell whether these usecases are supported. @wichert does. Anyway, adding missing parts if there are some are worth the work, maybe in a desired lingua.plone addon.

[jensens]

@vincentfretin do you mean with "non-standard-po" that what we - iirc - call "literals" in i18ndude?

[wichert]

@vincentfretin What makes you say msgmerge does not support that? Both i18ndude and lingua insert those default texts in a standard comment, and msgmerge preserves those when merging.

[wichert]

@vincentfretin lingua supports the whole i18n syntax, and has no problem with msgid in i18n:translate attributes.

If you find anything missing in lingua please file a new issue and I'll look at implementing that.

[vincentfretin]

@wichert As far a I know, msgmerge doesn't mark a message as fuzzy if the default message changed. This is what I meant about msgmerge doesn't support of non standard po. As you say, it just keeps it as a comment. (someone should verify this)
@jensens I don't know what "literals" means in i18ndude.
Just to clarify, what I mean by non standard po (in the sense that msgmerge will not mark as fuzzy your message if the default message changed):

msgid "Search"
msgstr "Recherche"

#. Default: "Search"
msgid "button_search"
msgstr "Rechercher"

using i18n:translate="button_search" in zope.tal

Standard po is like this:

msgid "Search"
msgstr "Recherche"

msgid "Search"
msgctx "button_search"
msgstr "Rechercher"

using i18n:translate="" i18n:context="button_search" in Chameleon

[rnixx]

@vincentfretin fuzzy flags are set properly as far as i can tell

[jensens]

@wichert, you write the xml extractor is kind of deprecated. would it be useful for scanning genericsetup profiles or would you use a different approach?

[wichert]

I think you misread the documentation. The extractor itself is not deprecated at all, just the name xml which is now an alias for chameleon.

[jensens]

ok, but question is, can it be used to scan GS-profiles? Afaik the structure/xml namespace is not different between chameleon and whats used for i18n in GS.

[wichert]

As far as I can remember it should work just fine.

[saily]

i switched back all projects to i18ndude, because i had several issues with lingua. Since the api changed with lingua 2.0 i did not have time to adapt all projects and the message_extractors are lacking documentation.

If lingua is now easier to use and well documented, i support the move.
I also wrote this blob post for lingua 1.6, see: http://widerin.net/blog/use-babel-to-translate-your-python-package

[mauritsvanrees]

In my 2012 i18n talk at the Plone conference in Arnhem I already hinted that maybe we could use Babel instead of i18ndude in the future:
https://github.com/mauritsvanrees/maurits.i18ntalk/blob/master/talk.rst#expected-changes-in-the-future

I only briefly mentioned it then, but these were the two biggest points then:

• Good: has zcml support (which i18ndude actually has not: you need to manually add them to an extra .pot file)
• Bad: currently extracts all domains (which Wichert above says was added in Lingua 2.0, released April 8, 2014)

[wichert]

One small clarification: lingua no longer uses Babel for various reasons; it is a stand-alone message extractor now. It does support use of existing Babel extractors to ease migration from Babel to lingua, but custom extractors are encouraged to use lingua's extension API.

[mauritsvanrees]

Pro babel: babel is much more popular than lingua:

• PyPI downloads for lingua: 7,000 in last month. (i18ndude 3,000)
• PyPI downloads for babel: 22,000 in last day.

Pro lingua: when using babel we would need lingua for extraction anyway, so might as well use it completely.

Note: I have not tried lingua the last few years, and babel only in one project.

[rnixx]

@mauritsvanrees I don't think package popularity (measured by download counts) is a pro here. The more mature a package, the less easy to get enhancements in.

UPDATE: ... in conjunction with possible pitfalls when dropping i18ndude in favour of lingua

[jensens]

Also @wichert developed Lingua for pyramid as primary use case, which is with chameleon + eventually zcml very similar to Zope/Plone. OTOH Lingua is very generic and pluggable. The plugin API is very pragmatic and easy to use. And he has a strong Zope/Plone background and knows what we are talking about

[gforcada]

@mauritsvanrees @vincentfretin with the recent improvements that you made, is there anything left to implement on i18ndude? Because at the end, if i18ndude already provides everything there's no need to change to something that provides exactly the same...

[wichert]

FWIW lingua has seen a fair number of improvements recently as well.

[jensens]

in my own projects i'll use lingua because in my opinion it's the further
developed package. its pluggability is superior. i.e the yafowil plug in
parses yaml form-definition files for i18n strings and writing it was no
big deal.

i'd really like to see a real feature comparison based decision rather than
a final 'no need to change' word.

just my 0.02 euro
Am 01.12.2015 10:52 nachm. schrieb "Wichert Akkerman" <
notifications@github.com>:

FWIW lingua has seen a fair number of improvements recently as well.

—
Reply to this email directly or view it on GitHub
#22 (comment).

[petri]

AFAIK, i18ndude does not support the full Chameleon syntax (I added #36 about it).

[gforcada]

Seems that we are keeping the kid in the block so far 😄