txp_pluginlocalizer: a convention for TXP plugin localization

candyman · 2009-11-03 15:04:59

Bloke, in another thread, wrote:
OK, firstly, the [GLOBAL] text is hard-coded in the plugin. If you want to change the actual text, you’ll need to go right to the bottom of the plugin and look for a string named is_global and alter the text on the right hand side of the => sign. That’s where you change all plugin strings if you want to localise the plugin into a different language.

This, remind me a thing that I’ve thought some time ago and that, after the proposal for a convention for the TXP plugins update, I would like to bring to the attention of TXP developers/plugin coders: a way to localize all the plugins using an external style.txt which the final user can translate in his preferred language (or dialect).

In Bloke’s case, there’s an useful plugin-specific replacement strings at he end of the plugin code: you only have to alter the string on the right hand side of the => sign with the preferred term ant it’s all. But it’s a rarity. On the other side, there’s another problem: when Bloke presents an updated version of the plugin you have to do some copy&paste work (hoping that no new variables has been added to the code).

Some coders don’t give any localization help at all and if you (like me) want to achieve an homogeneous result from linguistic point of view, you have to search in the plugin code for the terms and translate them.

If you don’t do this you’ll get a admin like this:

with some terms localized and some others not.

It’s not all: some terms that, I presume, are part of the standard TXP localization packets (Italiano.txt, in my case) are correctly translated (look at [Modifica]) some others not ([Base], [Export]) even if they are part of the same plugin (I’ve take Bloke’s wonderful smd_admin_themes as example but this is valid for the most of TXP plugins).

So, my question is: could be done a system to get some localization-file.txt in the same way I’ve already seen with the zem_contact_lang that went with zem_contact_reborn plugin? It would be better a system that avoid to show two separate items (plugin+his localization) but which helps to change the strings using a new option in the TXP core. I mean: beside the Edit and Help management options in the Textpattern => Admin => Plugins page, could be add a brand new Translate (or Localize) option? It would be a wonderful opportunity from my point of view.

Thanks for your attention.

Last edited by candyman (2009-11-03 15:16:00)

Bloke · 2009-11-03 15:21:12

wet has proposed this idea, though as far as I know nothing concrete has been decided on exactly how to go about it yet. I think it’s a terrific idea and now is as good a time as any to thrash it out.

EDIT: btw, some strings are localised and some are not because I reuse a string if TXP has already defined it. In this case, ‘Edit’ exists in the txp_lang table but ‘base’ and ‘export’ (among others) do not. Hence those ones are in my own ‘localization’ table at the bottom of the plugin.

Last edited by Bloke (2009-11-03 15:24:47)

candyman · 2009-11-03 15:31:17

Bloke wrote:
wet has proposed this idea

D’oh!

Bloke wrote:
some strings are localised and some are not because I reuse a string if TXP has already defined it. In this case, ‘Edit’ exists in the txp_lang table but ‘base’ and ‘export’ (among others) do not. Hence those ones are in my own ‘localization’ table at the bottom of the plugin.

Thanks, I’ve imaginated that, anyway this help me to understand TXP logic and make smarter questions in future…

Maybe a simpler solution could be make a list of approved TXP terms (a txp_lang table larger than the one actually present) from which plugins authors have to pick up the words? Export and Preferences I think are mature yet.

Last edited by candyman (2009-11-03 15:32:16)

Bloke · 2009-11-03 15:34:37

Actually, now is a very good time to discuss this because we’re beginning the project to completely overhaul textpattern.org. It is going to become solely responsible for plugins. To that end, it would make sense for authors and contributors to be able to upload — or somehow attach — language packs to particular versions of plugins.

When a plugin is served there’s nothing to stop someone requesting the plugin in Italian or whatever. If there was a list of available language packs near the download button, txp.org could either amalgamate the language pack and the plugin itself on the fly (base64-decode, search ‘n’ replace the language function, base64-encode, deliver) or could offer it as an additional download alongside. Or, simply as a list of translation packs that you can choose to download separately.

The trick here is going to be associating a language pack with a particular plugin version because, as you say, strings change between versions. We’re looking at some similar options during the txp.org redesign for compatibility purposes so I’ll take it back to the team and see if anyone has any cool ideas we could share.

Last edited by Bloke (2009-11-03 15:38:54)

thebombsite · 2009-11-03 19:23:23

I had a very similar thought back in February 2006, just after introducing the separate language file for ZCR. Doesn’t time fly? ;)

Thinking back to my thoughts of that distant past my idea was that there would be a language file containing all gtxt calls from all plugins. Then there would be translations of the file. When someone installed a plugin Textpattern would know which language file was being used for the site and call all gtxt outputs from the appropriate translation.

My only problem with this was where would the files be stored? If they were stored somewhere like textpattern.com would this noticeably slow down the plugin and of course what might happen if the host site was down for any reason. This led me to the conclusion that the file would best be stored locally but the logistics of setting up all the downloads for the different language files plus getting them all translated in the first place plus the fact that the files were likely to need updating on a weekly, if not daily basis kind of turned me off.

It also reminds me a little of that discussion we had about plugin authors using existing class and id nomenclature so that they would “inherit” whatever admin style was currently being used by the site they were installed on. One day…

Last edited by thebombsite (2009-11-03 19:35:38)

els · 2009-11-03 20:32:32

Bloke wrote:

Or, simply as a list of translation packs that you can choose to download separately.

Can MLP be a source of inspiration here? Of course I’m not a coder and I have no idea if how MLP works could be used in other areas, but it has its own language packs, for MLP itself and a couple of other plugins, that can be submitted and downloaded (the .inc files). Importing them adds them to the txp_lang table. A column is added to the table to identify the plugin that uses the strings.
The plugin writers wouldn’t have to maintain the translation files, that’d be up to the users.

A while ago I managed to extract the text strings from yab_shop and create a separate plugin like zem_contact_lang. It even worked ;) though because the plugin unfortunately didn’t work with MLP in other areas I gave up on it (and if I had to do it again now I’d have to figure it out all over again…). I’d be very grateful if you could come up with something so I won’t have to do it again ;)

Gocom · 2009-11-04 00:17:27

Bloke, are you saying that key features might be:

Enduser: Interface where s/he can insert new sting.
Plugin Author: Compined function to insert and update strings easily. Syntax example #1-1.
Translater/plugin author: option to upload whole new translator files (well, there is already a feature for that, but bit of improved visuals wouldn’t do bad).

Possibly some standard restrictions could be nice too:

Plugin author needs to use plugin author prefix before the string.
…If they don’t, we beat them with really soft sticks.
We need really soft sticks.

Syntax example:

insert_update_lstring(
	array(
		'xxx_i_like_my_flakes_raw' => 'Happy creep-ures live in the woods.',
		'xxx_theme_update' => 'Make world better place'
	),
	[language/s|area|etc]
);

PS. yes, my upcoming plugin uses “xxx” prefix and it’s called xxx_i_like_my_flakes_raw. True story example.

candyman · 2010-03-03 22:07:34

Solution in progress.

Last edited by candyman (2010-03-03 22:08:01)

Textpattern CMS

Textpattern CMS support forum

#1 2009-11-03 15:04:59

txp_pluginlocalizer: a convention for TXP plugin localization

#2 2009-11-03 15:21:12

Re: txp_pluginlocalizer: a convention for TXP plugin localization

#3 2009-11-03 15:31:17

Re: txp_pluginlocalizer: a convention for TXP plugin localization

#4 2009-11-03 15:34:37

Re: txp_pluginlocalizer: a convention for TXP plugin localization

#5 2009-11-03 19:23:23

Re: txp_pluginlocalizer: a convention for TXP plugin localization

#6 2009-11-03 20:32:32

Re: txp_pluginlocalizer: a convention for TXP plugin localization

#7 2009-11-04 00:17:27

Re: txp_pluginlocalizer: a convention for TXP plugin localization

#8 2010-03-03 22:07:34

Re: txp_pluginlocalizer: a convention for TXP plugin localization

Board footer