- This topic has 43 replies, 3 voices, and was last updated 15 years, 10 months ago by
.
-
Posts
-
Hi, just now saw <a href="http://transientmonkey.com/wp-slimbox2#comment-165">your reply</a>, and that was after I discovered in the plugin settings at my place that you have more or less quietly added Picasaweb support! Woohoo! (Just a minor and tangential observation there: it refers to "an appropriate thumbnail" but I have a hunch that lazy bums, like me, might like an example snippet as a quick reference…)
Now, about localizing the plugin: I’m more than happy to give you Spanish and Dutch translations, and just now looked at the files but frankly I’m not sure where to start digging. I suspect <b>adminpage.php</b> is where the action’s at – could you confirm that’s where the UI strings are? And, just as a quick workaround suggestion instead of laboriously reworking for a Gettext type setup (for including .po and .mo files, like in WP itself) maybe it’s an idea to work with a separate file containing the localized strings (e.g. in a language_XX.php file, where XX represents a two-letter language code) that’s included by adminpage.php to swap out the UI strings, upon selecting a language switch there*.
Anyway, that’s just looking ahead – right now I’m looking for the place where to start typing. Is that indeed adminpage.php (and none other)? Thanks!
*Added later: obviously it’s more recommendable to go with the <i>given</i> language of the WP install (as set in WP’s wp-config.php file) but…
You are quite right, adminpage.php is where the UI strings are located.
I know almost nothing about localization (I’ll even confess it hadn’t occurred to me until you suggested it), but I certainly think it’s a good idea.
It seem like, in theory, it shouldn’t be too difficult, but I’ll need to look into it myself.
I’ve been meaning to put together some sort of broader FAQ with examples of certain things, but I never have gotten around to it. I probably should, though at the same time I’ve been wanting to get a few more feature implemented as well. I think for now I’ll concentrate on prepping the code for using localization (unless you’re offering to do that as well), a feature similar to the picasaweb and flickr autoloads for gallery2 (in case people don’t want to use WPG2 and it’s lightbox setting for some reason), and then maybe I’ll work out a more elaborate FAQ.
Thanks again for your offer of assistance in localization, hopefully others will provide additional translations as well.
Well, I’m not much of a PHP coder so I can’t be of much help with mods necessary to accommodate localized strings in a given way (e.g. Gettext support) but as one example of a plugin that swaps out the English (default) language UI strings with a localized version of them (if available of course!) I could point to the <a href="http://wordpress.org/extend/plugins/xhtml-video-embed/">XVE plugin</a> (which I’ve also helped localize). Essentially, the UI strings in XVE are defined (declared) in separate language-specific files. The plugin’s code looks at what the user’s desired language is (it’s set by the user in the plugin’s option / settings page), then checks whether that language is available in a specific plugin subdirectory containing all the localized language files (one for each language pair, e.g. English > German) and then pulls the UI strings from that file. The key "trick" is enforcing a naming discipline (convention) for those language files, say "language_ES.php" for Spanish, whereby in that example the used two-letter language code (ES) <b>must</b> conform in <b>every</b> submitted localization (translation) file to the same standard, e.g. as used in the WP installation. That makes automated checking for an available translated version and including that much easier.
Moreover, it’s a relatively simple solution that keeps your plugin code separated from the UI string definition files, with an (almost) unlimited flexibility for adding new language pairs (i.e. localizations) as they become available, in principle without having to modify a single bit of your code. And as far as I can tell, with that roughly described method, changing the code in adminpage.php to look for the UI strings in a separate language file could also work with .po / .mo files (they essentially identify each string with msgid="original" and msgstr="translation").
Anyway, I’ll get busy now and when I’m done, post a translated adminpage.php for Spanish, attached here; the zero-effort method would be to simply create a complete WP-Slimbox2 plugin package with a translated Spanish adminpage.php, but that gets messy when you have several languages…
Dunno. Will think about that as I work along.
OK – I’ve done the Spanish translation; it’s attached to this post. <s>Two</s> three observations:
First, I think localization doesn’t make much sense without also modding the used WP-Slimbox2 images (close, next, prev). However, before implementing that I’d recommend setting up a separate sub-folder for translations and related image files; else you end up quickly with a very cluttered plugin folder. So, I didn’t change the image files*. Also, there’s the issue of changing the default navigation keys; as those are handled (set) elsewhere, in another file (perhaps even in JS code). Same for the default Text counter value of "Image {x} of {y}". So, that’s why I didn’t change the given default values in English, even while the keys refer to English words (e.g. "n" for Next).
Secondly, I’ve tested my quick translation hack by subbing out the file; nothing exploded, everything appears to work fine.
Thirdly (added later): because there are a bunch of accents, and to keep potential validation issues at bay, I’ve converted all "funny" characters in my translations into their HTML entity versions, for sanity purposes.
*In case you’d like to keep control of the image files (i.e. for consistency of color, font, placement etc.) I can give you the translation of those right here:
"CLOSE" > "CERRAR"
"Next" > "Sig." (that’s an abbreviation for "Siguiente")
"Prev" > "Ant." (that’s an abbreviation for "Anterior")Lemme know if this works…
I’m a bit busy at the moment, but I’ll attempt to find time to look these over.
As for the images, the originals were actually created by Christophe Beyls, the creator of Slimbox.
Keeping consistency is probably a good idea, though I’m no good at creating images. If someone else wants to take on that task, and is willing to produce them for translations as well that would be appreciated. That said, I’m trying to think of a good way to automatically localize the image files without running the css through the php engine, but don’t have one yet. I’m open to suggestions, though. Actually…I might be able to do it with jQuery similar to how I added the overlay color change without touching the CSS….
I’m sorry I can’t be of more use with coding, but if an example is of any help: XVE is handling it via an array in PHP (in the current version – 0.3.6) to load the UI strings. The localization support bits start at around line 702 in the file xhtml-video-embed.php (the plugin’s main code file). It’s nifty, in that it builds the list of available languages from reading available files – i.e. the language options aren’t hard-coded, so adding a new language should be just a matter of plopping in that additional file, and you’re done. Of course, in the case of WP-Slimbox2 I suspect there could be a problem in passing PHP array values around, i.e. to JS / jQuery… That’s why I’d rather not make code recommendations here, I simply don’t feel confident enough.
Some useful links to help with localization of plugins:
http://weblogtoolscollection.com/archiv … ng-poedit/
http://urbangiraffe.com/articles/locali … d-plugins/I’m reading them up now to see if I can figure this out for my own plugins.
And another helpful link from Andrew Rickman:
Urgh, I’ve been trying to get this to work, but I keep getting errors
” title=”Sad” />I’d rather use the standard .po/.mo file approach if possible as that seems to be the preferred method and the one used by WordPress itself.
Yes, the Gettext method (using .po and .mo files) is also far easier for translators… After perusing the information in the links you just posted, I’m tentatively reaching the conclusion that there’s not <i>that</i> much more complexity involved in preparing the code for Gettext and the method of using hard-coded PHP array files. Still, I readily accept that it’s a royal pain in the neck to go over all UI strings and hooking them into a semi-separate routine.
On the other hand: the benefit of handling all UI strings separately is that it makes hunting for typos/style improvements in <i>any</i> language so much easier. However, in the case of WP-Slimbox2 there’s also the issue of placing image files in the corresponding languages folder, and adapting the paths correspondingly.
I’m very certain in either case that, once more translations are available, you’ll see many more people adopting and using your plugins (and themes – but that’s a major step…) Once people <i>understand</i> how to mesh together customized templating and navigation (menu) organization, and add UI improvements such as in this case via WP-Slimbox2, the intertubes will become a prettier place.
(And therefore: thank you both for your willingness to look into localization!)
I think many people just don’t realise that non-English speakers care about this type of thing.
I have received emails asking about localization support, but I assumed that was for localizing the front-end, not the back-end so just told them that I would add an option to change the titles of the various menu items, thinking that would be good enough. It’s just human ignorance, but unfortunately I don’t see that changing any time soon.
We will get this working
” title=”Smiley” /> I just need to figure out what I’m doing wrong.Do you know of any really tiny plugins which use the Gettext method? Something which does almost nothing, but has localization support would be handy to work out how to do it as there would be less junk code to read through to find the localization stuff.
Took me a bit to search through my pile of plugins, but I think <a href="http://wordpress.org/extend/plugins/adminimize/">Adminimize</a> is both interesting and "small" (and current, i.e. WP2.7 compatible).
Good news, I’ve just finished implemented the standard translation engine, or whatever you want to call it, to utilize .mo and .po files. To make sure it worked I transferred in the text from the file you provided, and configured my test site to Spanish, and it worked like a charm.
I’m going to try and tweak a few default settings to correspond to the native languages as well as pointing to alternative images. Once I think that’s done I’ll release the POT file, as well as the es_ES .mo and .po for you to mess with. Assuming it looks right to you I’ll likely release a new version with language support and the Spanish translation.
My that’s fast… Well, lemme know and I’ll be happy to check it. One thing: as .po / .mo ought to be UTF-8 there’s little point in messing with HTML entities within them. So perhaps it’s easier if you display the strings and them copy them as rendered (of course, easiest yet is me checking!) Hats off to Team Lightning here…
- You must be logged in to reply to this topic.