Return to WP-Slimbox2 Support

Localizing (translating) WP-Slimbox2

Home Forums WP-Slimbox2 Support Localizing (translating) WP-Slimbox2

This topic contains 0 replies, has 3 voices, and was last updated by  nv1962 11 years, 5 months ago.

Viewing 15 posts - 1 through 15 (of 44 total)
  • Author
    Posts
  • #1702

    nv1962
    Member

    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…

    #1745

    Malcalevak
    Keymaster

    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.

    #1744

    nv1962
    Member

    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.

    #1743

    nv1962
    Member

    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…

    #1742

    Malcalevak
    Keymaster

    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….

    #1741

    nv1962
    Member

    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.

    #1740

    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.

    #1739

    And another helpful link from Andrew Rickman:

    http://www.wp-fun.co.uk/2009/01/13/prem … le-themes/

    #1738

    Urgh, I’ve been trying to get this to work, but I keep getting errors <img src=” 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.

    #1737

    nv1962
    Member

    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!)

    #1736

    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 <img src=” 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.

    #1735

    nv1962
    Member

    Took me a bit to search through my pile of plugins, but I think <a href="http://wordpress.org/extend/plugins/adminimize/">Adminimize</a&gt; is both interesting and "small" (and current, i.e. WP2.7 compatible).

    #1734

    Thanks. I’ll hopefully get a chance to take a look at that tomorrow.

    #1733

    Malcalevak
    Keymaster

    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.

    #1732

    nv1962
    Member

    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…

Viewing 15 posts - 1 through 15 (of 44 total)

You must be logged in to reply to this topic.

css.php