Adding language string in plugins...

Zanza · 2008-06-21 11:20:37

…is there a “right” way?

I’m looking at some old plugins (not of mine) and trying to make them work. I’m not sure how I should insert language strings added to the default language strings.

Thanks for any hint.

Z-

jm · 2008-06-21 11:43:42

Check out this guide from net-carver.

net-carver · 2008-06-21 12:46:28

Zanza

Those old plugins you mentioned; do they have their strings scattered through the code — or are they all in one routine that gets called in order to show them (similar to Textpattern’s own gTxt() function?

If they are already gathered in one place then most of the work is already done.

Zanza · 2008-06-21 13:39:44

Thanks JM and Steve. I’ll look into the file you pointed.

@Steve: One plugin is md_version, that is not working on 4.0.6 (author Martin Dostal is not active here, afaik). I managed to install db table (which routine seemed broken) and, with of couple of db-related bugfixes, now actually everything is working, but language strings are hardcoded for two languages, cz and en, in the plugin, using this schema:

$l['en']['md_version_new_version_for_article']="Add new version for the article";
$l['en']['md_version_view_all_articles']="All saved articles";
...

This is working fine if you have cz or en languages activated. But if you have another language, the strings are not working. To say, instead of “All saved articles” you get the array index: md_version_view_all_articles displayed, that is weird. (added: I’d rather have the english text by default, instead of array index…)

It do make use of gTxt function, but maybe the way the lang array is build is not correct. I’ll dive into it.

Also, I’d like to have all lang strings coded in a more “standard” way, also to have them eventually working with your wonderful MLP. :)

Last edited by Zanza (2008-06-21 13:44:21)

net-carver · 2008-06-21 16:01:59

Zanza

This is working fine if you have cz or en languages activated. But if you have another language, the strings are not working. To say, instead of “All saved articles” you get the array index: md_version_view_all_articles displayed, that is weird. (added: I’d rather have the english text by default, instead of array index…)

That’s standard txp output when the language string you are looking for doesn’t exist in the current language of the site. To get rid of the error you’d need to provide translations of each string in your target language(s).

Just been browsing the install code in that plugin and it writes all the strings to the txp_lang table. It would be simpler to have a local gTxt() routine or simply use the mlp-wrapping one from sed_plugin_library. (Which does most of what I wrote about in the document Jon-Michael pointed you to.)

You could do this…

	@require_plugin('sed_plugin_library');

	$strings['tab_md_versions']="MD versions";

	//headers
	$strings['md_version_new_version_for_article']="Add new version for the article";
	$strings['md_version_view_all_articles']="All saved articles";
	...
	(etc)
	...
	$strings['md_versions_no_comment']="no comment";
	$strings['md_version_saved_versions']="Saved versions:";

	$mlp = new  sed_lib_mlp( 'md_versions' , $strings , '' , 'admin' );

Then whenever you want to show a string, you do this…

$mlp->gTxt( 'md_version_saved_versions' );

This will work with or without the MLP pack. The advantage of having the MLP Pack is that you can now quickly add new languages to the site and translate all those English strings into whatever language(s) you choose.

In fact, you can use the Pack’s export feature to produce a text file of your translated strings for the md_versions plugin and post it somewhere so others can share it.

Bloke · 2008-06-21 19:05:56

net-carver wrote:

…or simply use the mlp-wrapping one from sed_plugin_library.

Hey, I recognise that code! Spookily similar to the routine in smd_lib ;-)

Good to see it has a proper home. Would it be beneficial to deprecate my version now and require people to install your library when using things like smd_slimbox, or should I keep mine around so they don’t have to have another library in addition to MLP on the (probably slim) offchance they’re not running one of your plugins?

I’d need to change slimbox and any of my MLP-aware plugins of course because they all rely on smd_MLP. Plus, I suppose I’d need some conditional logic to test if your library’s available and just serve local gTxt routines in the eventuality it’s missing? Would be nice if we could find a standard way for the MLP side of things to ‘fail’ gracefully if your library isn’t installed and revert to the local / txp_lang strings in that case. Is that easy to accomplish do you think?

fwiw, I’d rather use your version because you can keep it in sync more easily with MLP if necessary, but I don’t mind having two similar functions available in parallel if it means it’s more flexible for plugin writers/users and means they have one less plugin loaded, given your possible performance discovery.

Last edited by Bloke (2008-06-21 19:06:58)

net-carver · 2008-06-22 06:50:58

Stef

You wrote…

Hey, I recognise that code! Spookily similar to the routine in smd_lib ;-)

Indeed spookily inspired by your library class. I figured I’d pop it in a my own library as it’s an excellent idea and I don’t use your library … ergh … yet.

Would it be beneficial to deprecate my version now and require people to install your library when using things like smd_slimbox, or should I keep mine around so they don’t have to have another library in addition to MLP on the (probably slim) offchance they’re not running one of your plugins?

I’d tend to keep it in both. Your code’s been out way longer than my latest library and you don’t know who is using your code.

I suppose I’d need some conditional logic to test if your library’s available and just serve local gTxt routines in the eventuality it’s missing?

I’d have thought you would have made your plugins depend on your library by doing a require_plugin('some_library');. In a similar way, you could make them depend on whatever library is doing the mlp wrapper. If you were to do that, then the mlp wrapper would take care of calling the gTxt routine or simply pulling the strings from the array the client plugin gave it.

Zanza · 2008-06-22 14:51:16

Steve, thanks, I’ll follow your advises as soon I can. In the trial installation that I’m using to mod md_version I’m not installing MLP, but I definitely want to make things compatible. So I’m going to install at least sed_plugin_library and let you know!

net-carver · 2008-06-22 15:02:46

Zanza

Ok. Make sure you grab the latest one from my site.

Zanza · 2008-07-25 14:57:30

I just have some question here, for Steve (or someone else).

As you’ve seen, the original plugin use a language specific array. With your suggestion, I don’t understand where I should write the multiple language strings. Should I mantain the $l[‘lang’][‘to_localize_string’] structure? Or just have one lang version only at a time?
It’s not clear for me if with your method the lang strings are saved in the db or modified in plugin source by user and loaded on the fly. It seems to me that they are loaded on the fly, and ask to be sure. Should I remove the db saving routine in the original plugin code?

I hope you’re subscribed to this thread… :)

Z-

net-carver · 2008-07-26 12:38:19

Zanza

hello — yes, subscribed!

If you intend running your modified plugin in an MLP Pack installation then you should just replace with one language — probably your native one or perhaps English if you wish to distribute your modified version. Then you can use the MLP Pack to provide as many translations to the plugin as your site might want (it stores them in the txp_lang db table.) You can also use the MLP Pack’s string import/export feature to share any such translations of the plugin with others or load their translations into your installation.

(Just to answer your second question: the method used by the MLP pack is based on strings in the db. However, the initial set of strings stored in the db has to come from within the plugin.)

However, if your don’t want to use the plugin in an MLP environment then I’d just extend the original author’s scheme and add as many languages as needed. This does have the advantage of it all being contained in the plugin.

Last edited by net-carver (2008-07-26 12:39:35)

Textpattern CMS

Textpattern CMS support forum

#1 2008-06-21 11:20:37

Adding language string in plugins...

#2 2008-06-21 11:43:42

Re: Adding language string in plugins...

#3 2008-06-21 12:46:28

Re: Adding language string in plugins...

#4 2008-06-21 13:39:44

Re: Adding language string in plugins...

#5 2008-06-21 16:01:59

Re: Adding language string in plugins...

#6 2008-06-21 19:05:56

Re: Adding language string in plugins...

#7 2008-06-22 06:50:58

Re: Adding language string in plugins...

#8 2008-06-22 14:51:16

Re: Adding language string in plugins...

#9 2008-06-22 15:02:46

Re: Adding language string in plugins...

#10 2008-07-25 14:57:30

Re: Adding language string in plugins...

#11 2008-07-26 12:38:19

Re: Adding language string in plugins...

Board footer