Localization support

[nv1962]

I’ve installed the plugin (v1.7.5) on my Spanish WP2.7 install, but even manually uploading "my" .po file it won’t load (show) the translated UI strings. I’ve even tried (an incorrect method, but just in case) to rename the pixopoint_mln-es_ES.po into pixopoint_mln.po but that won’t load, either.

Also, I can’t find the one string you mention in the included unlocalized.txt file, anywhere in the included pixopoint_mln.po file…

Am I doing something wrong?

[nv1962]

<b>UPDATE: IT NOW WORKS 100%</b>

Here’s a new and improved set of .po and .mo files attached to this post (double-checked now, up-to-date for v1.7.5, removed all simple quote backslash escapes). <s>I have no idea if their name is correct, but I think this should be getting closer. The problem is that the plugin itself doesn’t find them…

Edited: it seems to be more helpful if the file is actually attached…</s>

<b>It’s done – and it works perfectly now. Feel free to distribute the enclosed <i>languages</i> folder – it requires one minor mod to the MLNP’s index.php file: just adding the path to the languages directory, and it’s 100% functional and will be automatically recognized and loaded by WP.</b>

I think I figured out where the problem was with WP not picking it up: in index.php there’s no indication of <i>where</i> to look for the language files. So, the line in index.php calling the textdomain function needs to be amended to show the path to the language files.

The current setup assumes that all language files (.po and .mo) go straight into the plugin folder. If you have a subdirectory for the language files named ‘languages’ then the line of code to look for in index.php is:

<b>load_plugin_textdomain (‘pixopoint_mln’);</b>

Change that to:

<b>load_plugin_textdomain (‘pixopoint_mln’, "/wp-content/plugins/multi-level-navigation-plugin/languages/");</b>

I’ve tested that and it picks up the language file fine – provided the language setting in WP’s wp-config.php is set to an available language file, of course.

Then, most importantly: you <i>must</i> include the .mo files. That’s what WP works with. The .po files are more for the benefit of other translators, who can use them to create another language translation based on one of them. No .mo file, no localization.

And finally, translated .po files <b>must</b> be named like this: pixopoint_mln-xx_XX.po and pixopoint_mln-xx_XX.mo where the xx and XX are the appropriate language/country 2-letter codes. The ‘textdomain’ bit is what tells WP what the .mo (and .po) files actually are named like, so that’s why following that naming convention for translations is imperative.

To make things easier for other translators / localizers, I’ve created a .pot (.po template file) that is included in the attached /languages folder; see the attached .zip below.

Plop the /languages folder inside the plugin folder, and modify that one line in the index.php file of the plugin, as shown above, and then in wp-config define the language as:

<b>(‘WPLANG’, ‘es_ES’);</b>

…and then it should all work.

Note: this is for Multi-level Navigation Plugin v1.7.5.

PS: there’s just one bit that needs localized: in the "menu contents" tab, under "main menu content", the texts for "Menu Item #1" "Menu Item #2" "Menu Item #3" etc. aren’t translated. Same for the secondary menu content; also, the select (pull-down) menu items appear all in English. I presume it’s hard-coded; I couldn’t change it. Other than that: if a change or update is needed, holler and I’ll attach it, as mods are quite trivial now that it works as it should. Finally!

[imported_Ryan]

THANK YOU VERY MUCH!

That is terrific and I’ll get to work as soon as I can. I have a lot of stuff I need to get done today, but hopefully I can get it all out of the way and have a new version with localization support running ASAP.

[imported_Ryan]

Here is the final product. Hopefully it works … http://downloads.wordpress.org/plugin/m … .1.7.7.zip

I don’t have time to test the language functionality right now, but the rest of it seems to be working fine at least.

If anybody tests out the new Spanish language support, please let me know to confirm that it is indeed working as expected ” title=”Smiley” />

[nv1962]

It doesn’t, because you didn’t modify the index.php file of your plugin. You need to change line 28 to the following:

load_plugin_textdomain (‘pixopoint_mln’, "/wp-content/plugins/multi-level-navigation-plugin/languages/");

Then it’ll work.

Perhaps you could upload a minor 1.7.7.1 update to reflect that?

Added PS: don’t forget, obviously whenever you get around to it and in a future version, to include a string that will be used <b>only</b> in non-English versions (i.e., that has an empty/null string in English) about support in English… Perhaps you could put that in the "Help" block, as the first item there.

[imported_Ryan]

Here’s a new version which corrects that problem:
http://downloads.wordpress.org/plugin/m … in.1.8.zip

I have a vague versioning system which involves point releases being significant upgrades and double point releases as being bug fixes or minor upgrades. Adding localization support counts as a significant upgrade in my book so the new version is 1.8.

I set my localhost to work in Spanish and the translation looks pretty slick! (apart from the bits which I haven’t sorted out for translation yet).

[nv1962]

Yep, that one works – thanks! I just caught something else though, fixed in the pack below:
– Instead of a .po file for other translators, it’s better to include a .pot file (essentially the same but it’s treated as a poEdit / Gettext template file; easier to manage). Fixed.
– I noticed that (silly me) the carets (‘<‘ and ‘>’) weren’t sanitized as HTML entities, so the menu code example given (in the <i>Home</i> tab, under "Free support") doesn’t show. Fixed.

Other than that, and <i>for a future point release</i> (as I don’t think it warrants yet another double point release) not only the select items I mentioned earlier in this forum topic need changing, but also the selectable settings options (e.g.: in the <i>Settings</i> tab, "high", "average", and "low" make little sense, left untranslated) so whenever you get around to that, lemme know and I’ll provide the translated versions. Also, in the <i>Menu contents</i> tab, the suggested names for menu contents and their titles really ought to be localized, as well. I’ll see if next week I can look into what could be done about that.

Main thing is that we got the localization engine working properly; now the rest is tuning and tweaking.

Thanks again for supporting localization.

[nv1962]

Have you seen the <a href="http://wordpress.org/extend/plugins/multi-level-navigation-plugin/stats/">download stats</a> for the plugin over at WP?

[Anonymous]

Hi there,
This is a very interesting thread. I work a lot with Hebrew and your menus work very well with that, except for one tiny thing, which I am not sure how to change: the sub-pages are indented to the left (which is cool in English, but looks wrong in Hebrew). Any idea on how to change that?

Thanks.

[imported_Ryan]

Hmmm, weird. I’d been wondering for a while if the menu would work in Hebrew actually. I was in Israel a few months ago and was wondering about it while I was there but never got around to trying it.

That issue is a CSS one, and I’ll need to have a serious look at how the indenting works to fix it in the CSS generator. If you have a specific menu you need fixed, then post it here in the forum and I’ll work out a quick hack to get it working for you.

[nv1962]

Ryan, you’ll run into that not only with Hebrew, but with any RTL (right-to-left) language in general, e.g. also in Arabic (that’s the other example that just now came to mind – they’re <a href="http://www.i18nguy.com/temp/rtl.html">not the only RTL languages</a> though). Perhaps the solution is to figure out a menu alignment / mirror-flip function, if one of the RTL languages is selected in wp-config.php so that the indentation also sits on the opposite (right-hand) side? I know, waaaaaaaay easier said than done…

Added: perhaps via another string in the .po/.mo file, to read which way the menu goes. A little bit like the per-language differing time/date string formats, that are used to figure out how to show ’em in themes – or the different way of handling plurals.

[imported_Ryan]

There isn’t really an easy way to do that dynamically. I think it is just a matter of setting up the CSS to work in either direction.

[malcalevak]

How much needs to be changed to support a RTL language? I would think as long as it wasn’t massively complicated you could do like nv1962 said, with some sort of
[code:27ywe0x0]if (__(‘RTL’)==’RTL’) echo ‘specific css for RTL languages’;[/code:27ywe0x0]
Another possibility would be to manipulate rules with jQuery, but that would only work on the menu’s that’ve loaded it.
Or maybe an additional set of CSS rules for class .RTL that’s added if their language is an RTL language?

I’m just throwing out ideas here, since I’m awful with CSS maybe Ryan is aware of something I’m oblivious too (like I don’t know what CSS is actually needed to display text as RTL).

Now if only I could get some more translations for WP-Slimbox2. Would RTL languages effect anything uniquely in it?

[imported_Ryan]

No, I’m sure that’s a piece of cake. The issue is with the CSS generator, I would need to have some way to manipulate the existing CSS. But the existing CSS is dynamic, the values for the CSS fluctuate. The script would actually need to rewrite the CSS, not just add something to it.

My preferred option is to just alter the way the CSS works so that it works either with RTL or LTR. That shouldn’t be too hard, but since I haven’t got on to rebuilding the CSS generator it won’t be happening immediately.

[nv1962]

One post, two quick comments on different stuff:
#1: I just came across the internationalization supporting menu selection solution in <a href="http://wordpress.org/extend/plugins/statpress-reloaded/">StatPress Reloaded</a> which I think has the localized options settings (i.e. in the plugin’s admin page) down pat nicely. Maybe a useful example; the plugin itself is just one file.
#2: Malcalevak, for RTL support in Slimbox2 I believe the only (but not unimportant) issue is that the movement is the other way around (i.e. "next" moves to the left, "previous" to the right) so you have to effectively switch those two around.

[Author]

Posts