Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Pages: 1
Proposal: Plugin localisation
Hello plugin developers!
I wasn’t sure if I should post this topic here or in the localisation forum. As you see, I ended up posting it here.
As English is not my native language, I’ve always been interested in the localisation of textpattern. After a lot of work, we have many localised strings in the database now, but one problem is still not solved: the localisation of plugins. Some plugins have to be revised line by line to find the language strings, others use a function to gather all the language information. If a plugin is updated, all localised parts are overwritten and you have to start translating it again.
Right now, I’m working on sort of an image organizer to get hold of a huge amount of uploaded images. I wanted to work out a way for an easy and working localisation of this plugin. This is my solution / proposal how to handle translations of plugins:
My idea is to use two plugins: one for the plugin code itself (1), the other for the language strings (2). If the first one needs to be updated, the second one can stay untouched.
Using Zem’s plugin template:
1. xyz_plugin_name
<pre><code>
// Plugin types:
// 0 = regular plugin; loaded on the public web side only
// 1 = admin plugin; loaded on both the public and admin side
// 2 = library; loaded only when include_plugin() or require_plugin() is called
$plugin[‘type’] = 1;
</code></pre>
2. xyz_plugin_name_lang
<pre><code>
// Plugin types:
// 0 = regular plugin; loaded on the public web side only
// 1 = admin plugin; loaded on both the public and admin side
// 2 = library; loaded only when include_plugin() or require_plugin() is called
$plugin[‘type’] = 2;
</code></pre>
All native English speaking people don’t need a localized plugin, so I save the English language strings in plugin (1), plugin (2) is only needed if you like to use another language:
1. xyz_plugin_name
<pre><code>
# —- BEGIN PLUGIN CODE —-
if (txpinterface == 'admin') {
// load language
global $xyz_plugin_name_lang, $xyz_plugin_name_local;
// include the language plugin if it exists
include_plugin(“xyz_plugin_name_lang”);
// only use localised strings if they exist
if(isset($xyz_plugin_name_local)) {
// load localised array
$xyz_plugin_name_lang = $xyz_plugin_name_local;
}
else {
// load English array
$xyz_plugin_name_lang = xyz_plugin_name_en();
}
// register callbacks
// create some things and use language array
register_tab(“content”, “xyz_echo”, xyz_plugin_name_gTxt(“hello”));
register_callback(“xyz_plugin_name_echo”, “xyz_echo”);
}
// function to get the stuff
function xyz_plugin_name_gTxt($var) {
global $xyz_plugin_name_lang;
if(isset($xyz_plugin_name_lang[strtolower($var)])) {
return $xyz_plugin_name_lang[strtolower($var)];
}
// return something, if no language strings are set for this variable
return $var;
}
// English standard texts
function xyz_plugin_name_en() {
xyz_plugin_name_en = array(
“hello” => “Hello World!”
);
return $xyz_plugin_name_en;
}
// function to do anything here
function xyz_plugin_name_echo() {
pagetop(xyz_plugin_name_gTxt(“hello”));
2. xyz_plugin_name_lang
<pre><code> # —- BEGIN PLUGIN CODE —-
// German translation array global $xyz_plugin_name_local; $xyz_plugin_name_local = array( “hello” => “Hallo Welt!” );
# —- END PLUGIN CODE —- </code></pre>What do you think of this method?
Greetings,
Nils
Offline
Re: Proposal: Plugin localisation
I use gTxt() within the plugin code and create language files for the admin side pages of the plugin and load the needed one into txp_lang. This allows the user to select a specific language file. Sencer wrote in a thread, that it’s planned, that the expressions of txp_lang will be only loaded for the corresponding event. So this would allow to load only the needed language data and to install only the needed language file.
For the public part of the plugin, I try to make it possible for the user to define the output using a txp form. This way he can define the needed expressions (i.e. the label of a submit button) himself.
Offline
Re: Proposal: Plugin localisation
That’s a nice idea, too, but I have one question: The plugin is written in English, so the language strings are saved in the database under lang=“en_gb”. My site runs in German translation: If there is a translation of the plugin, new strings are saved unter lang=“de_de”. But what do you do, if there are no German language strings installed? How to fall back to the English strings?!
Last edited by Skubidu (2005-10-25 08:00:47)
Offline
Re: Proposal: Plugin localisation
Maybe I don’t understand your point…
but my plugin is not written in English, it’s written in PHP. :-)
The plugin itself doesn’t contain any language strings and there’s no saving of these by installing the plugin code itself. The user has to install the plugin code and then install the desired language file by using the txp language upload function. The language strings used are those according to the central language setting of Textpattern, so if you have txp in German then the german language strings of the plugin are used. If you change the language setting in Textpattern, the plugin language will change, too.
Offline
Re: Proposal: Plugin localisation
but my plugin is not written in English, it’s written in PHP. :-)
Witzbold ;)
The plugin itself doesn’t contain any language strings and there’s no saving of these by installing the plugin code itself. The user has to install the plugin code and then install the desired language file by using the txp language upload function. The language strings used are those according to the central language setting of Textpattern, so if you have txp in German then the german language strings of the plugin are used. If you change the language setting in Textpattern, the plugin language will change, too.
Okay, then we are talking about different things: I can use textpatterns gTxt() for everything that has been translated for the standard admin interface. If I write a admin plugin, there can be many language strings, that are not in the database. It seems that I misunderstood you and thought you would add your own language strings to the database.
Last edited by Skubidu (2005-10-25 09:59:12)
Offline
Re: Proposal: Plugin localisation
“…and thought you would add your own language strings to the database.”
That’s exactly what I do. I use all (default) existing language strings and call them with gTxt. For those missing in the database, I create a language file that the user has to add to the database. These strings are then called by the plugin again with gTxt.
Last edited by tranquillo (2005-10-25 10:14:10)
Offline
Re: Proposal: Plugin localisation
Okay, then I have to ask again:
- I’m using one of your plugins.
- I installed the German language file for this plugin.
- I switch languages in admin interface, let’s say to French.
- What’s happening if no French language file is installed for the plugin or does even not exist? Is there any “fall back” to English?
- How to create my own translations without searching the database?
Last edited by Skubidu (2005-10-25 10:33:34)
Offline
#8 2005-10-25 11:59:54
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Proposal: Plugin localisation
I use gTxt() wherever I can, the rest goes into its own pluginname_gTxt().
Separating it into two different plugins is an interesting idea. My worry would be the space all these language plugins would take up in the plugins page. I don’t know about others, but my largest plugins don’t have very many strings to translate.
Not knocking the idea, I’m just mulling it over. :)
Offline
Re: Proposal: Plugin localisation
Hi Mary!
I think your right with your worries. There are two possibilities:
- You can manage languages strings for all your plugins in one language plugin (this reduces the additional plugins)
- Textpatterns plugin management is changed so that some kind of language plugin isn’t shown up (
$plugin['type'] = 3; // language file). If the language strings are separated from the plugin itself, there will be the possibility to translate the plugin help, too. So:
- xyz_plugin_name | Mr. X | 0.1 | test plugin | yes | edit | help
- xyz_plugin_name_lang | Mr. X | 0.1 | test plugin| yes | edit | help
would become
- xyz_plugin_name | Mr. X | 0.1 | test plugin (language name) | yes | edit | help
Offline
Pages: 1