Localization support

[r-a-y]

Report from cbox.org:
http://commonsinabox.org/groups/help-support/forum/topic/translating-commons-in-a-box/

In engine\infinity.php, the textdomain is set to infinity. This should be defineable so child themes can change the textdomain. Also, we need to package a .pot file so translators can use it.

Should probably move this issue to Infinity,

[boonebgorges]

Should beware making it definable; it's unclear how gettext is able to parse variables/constants. http://markjaquith.wordpress.com/2011/10/06/translating-wordpress-plugins-and-themes-dont-get-clever/ (read the comments too)

In any case, it should be possible, at the very least, to generate multiple .pot files - there should only be two, which is annoying, but not the end of the world.

[merolino]

Hi,
In the files I find 'cbox-theme' as textdomain

I have use the pot file you made boonbgorges for the backend and with poedit I have add (using sourcepath . and ..) all the frontend expressions in this pot file, but (I try almost everything I find on the web, I not developer I just want to use cbox in french) the file does not load.

[boonebgorges]

A quick search though the theme makes it look like the infinity
textdomain is never being loaded, but the cbox-theme textdomain never
is. Does that look right to anyone else?

On 07/23/13 06:41, merolino wrote:

Hi,
In the files I find 'cbox-theme' as textdomain

I have use the pot file you made boonbgorges for the backend and with
poedit I have add (using sourcepath . and ..) all the frontend
expressions in this pot file, but (I try almost everything I find on the
web, I not developer I just want to use cbox in french) the file does
not load.

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

[r-a-y]

@boonebgorges - Textdomain is loaded here:
https://github.com/cuny-academic-commons/cbox-theme/blob/master/engine/infinity.php#L184

@merolino - Language files should be placed and named accordingly:
wp-content/languages/infinity-xx-XX.po
wp-content/languages/infinity-xx-XX.mo

(where xx-XX is your locale)

Note that CBOX Theme has both 'infinity' and 'cbox-theme' textdomains at the moment.

[merolino]

Ok, sorry I'm new to infinity on all my precedents themes I was using languages files in the theme directory.

hum so, we have a pot file for infinity and not for cbox-theme,right ? Can we use both at the same time if we load cbox-theme in the functions.php ?

I'm not a professional but if I can help doing something just tell me

Thanks for the answers !

[boonebgorges]

Thanks, @r-a-y. But that only loads INFINITY_TEXT_DOMAIN, which is
'infinity'. Any string with the textdomain 'cbox-theme' wouldn't be
loaded in this way, right?

On 07/23/13 15:35, r-a-y wrote:

@boonebgorges https://github.com/boonebgorges - Textdomain is loaded here:
https://github.com/cuny-academic-commons/cbox-theme/blob/master/engine/infinity.php#L184

@merolino https://github.com/merolino - Language files should be
placed and named accordingly:
wp-content/languages/infinity-xx-XX.po
wp-content/languages/infinity-xx-XX.mo

Note that CBOX Theme has both 'infinity' and 'cbox-theme' textdomains at
the moment.

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

[r-a-y]

That's right. I was thinking we should probably switch all the
'cbox-theme' textdomains to INFINITY_TEXT_DOMAIN just to be consistent.
I do recognize the problem with using a constant for the textdomain, but
I think we should do whatever Infinity is doing.

It's either that or switch all the textdomains to 'cbox-theme', which is
probably not what we want to do to avoid any problems with merge conflicts.

I guess we can also bundle our own 'cbox-theme' .pot file and load it
alongside Infinity's, but I don't like having separate localization
files scattered all over the place.

How do child themes usually do localization? Do they use a mixture of
the parent and child themes for textdomains?

[MrMaz]

Ok, you guys have suffered long enough... going to jump in and shed some light now!

When I wrote the very first Infinity code way back in 2010 we really struggled with the proper way to implement i18n for the whole parent/child and/or forked templates theme setup. The WordPress standards for translation are not friendly at all to modular themes. In fact, their theme submission rules require that you have only ONE text domain and that it EXACTLY matches your theme "slug" (directory name). This causes all kinds of redundancy issues if you are forking a base theme with 100s or 1000s of strings that will be identical in many .pot files.

So quite simply, I created a constant (all lower case) to serve as a place holder until we figured out how to handle it. That is all it is, just a place holder, not a tricky strategy or anything. If you download the WordPress translations tools there is actually a utility for "adding text-domain to all gettext calls" which was what I planned to do at some point.

Discuss!

[r-a-y]

When I wrote the very first Infinity code way back in 2010 we really struggled with the proper way to implement i18n for the whole parent/child and/or forked templates theme setup.

I came across this function on the WP codex - load_child_theme_textdomain().

That looks to be the official way to load language files for child themes, however the problem with CBOX Theme is it's a fork of Infinity.

The WordPress standards for translation are not friendly at all to modular themes. In fact, their theme submission rules require that you have only ONE text domain and that it EXACTLY matches your theme "slug" (directory name).

If that's the case, that sucks for anyone working with bundling plugin templates in their theme!

So quite simply, I created a constant (all lower case) to serve as a place holder until we figured out how to handle it. That is all it is, just a place holder, not a tricky strategy or anything.

No problem, @MrMaz ! We'll hopefully be able to think of something!

If you download the WordPress translations tools there is actually a utility for "adding text-domain to all gettext calls" which was what I planned to do at some point.

I've tried WP's translation tools. The generator outputs a .pot file, but like you said, it adds strings for all textdomains it finds.

WooCommerce ran into a similar problem when they needed to separate their frontend and backend .pot files while using WP's translation tools. They hacked makepot.php to make this happen:
https://gist.github.com/GeertDD/4409092

Perhaps, it's something we could consider. Although, it would be ideal if we could pass on the textdomain to makepot.php.

[MrMaz]

I think you get it! You will fully understand my angle if you focus on the "forking" aspect.

If I have a parent theme that I want to extend, and I copy 3 of the parent templates into the child theme to customize them, I now have the parent theme's text domain in my child theme! You are now required (by repo submission rules) to modify the text domain of the gettext calls in the FORKED templates to match that of your child theme. The reasoning is that they must still get translated if the parent theme decides to remove one of the strings.

Of course as you mentioned, if you fork an entire theme, then you are really up a creek.

Btw, the utility I was referring to isn't the makepot script, its another one which actually traverses all of a theme or plugins source code and injects the text domain into any of the gettext function calls.

The crappy part is not the gettext calls themselves, its having multiple pot files to maintain and translate, all of which are 95% identical.

[boonebgorges]

@MrMaz - How are you currently managing the forked aspect? When you have upstream changes in Infinity, are you just using a git merge to bring them into the forks? Or do you have a more sophisticated script?

.pot generation and maintenance is pretty easy, with scripts like makepot.php - you can just roll it into a deployment script. On the other hand, I have no idea how to manage the translations themselves. Obviously, since someone has already translated Infinity's strings into (say) German, you'd want to include those translations in the forks. But I don't know of a tool for making that happen. Maybe some of it would happen automatically just by changing the translation filename from infinity-de_DE.mo to cbox-theme-de_DE.mo, since the strings mostly remain in the same files in the fork, and the line numbers for gettext are fuzzy anyway?

[MrMaz]

@boonebgorges - yes, its pretty much a waterfall workflow. rarely do downstream changes get merged upstream.

I was thinking along the same lines, to have some kind of "transformation" script that merges two pot files in to one under the same text domain. All of this would require quite a bit of research and testing, which is exactly why it has been put off for so long, lol.

[christianwach]

Was there ever a conclusion to this? I'm struggling to get a German CBOX install working as expected.

[MrMaz]

The new Infinity core supports this, but I still have to do a mass search/replace for strings.

[christianwach]

OK, thanks @MrMaz do you happen to know of any short-term hacks I can use? My experience has been that translations can be fragile when things change.

[r-a-y]

@christianwach - Short-term fix is to use the 'gettext' filter on the strings you need to change.

You can also use a similar, but slightly different, approach that Paul from bp.org used:
http://byotos.com/2010/04/08/hijacking-wordpress-internationalisation/

[christianwach]

@r-a-y That's the ticket. Thanks!

So am I right in thinking that eventually the entire file tree will be assigned to a single text-domain? I've been trying out translation "helper" plugins like Loco, which allow users to generate their own updated .po and .mo files through a UI. Loco, however, won't handle multiple .pot files for a theme - or rather, I can't can't seem to get it to do so. Given this (and the fact that I'd rather delegate the responsibility for translation via a UI) I'd be in favour of standardising around a single text-domain, whichever one happens to be chosen.

[christianwach]

One thing I'm curious about @MrMaz - how are you proposing that we handle (for example) "Activity Stream Tour" text? At present, it seems to exist only in 'engine/extensions/features/bp/tour/options.ini' with no filtering capability between the ini file and the html output, thus rendering it untranslatable as far as I can tell.

[MrMaz]

The new core does not use INI files. It's all array based now, so the strings can be passed to getttext.