[dokuwiki] Re: Internationalization in plugin descriptions (via plugin.info.txt)

  • From: Luis Machuca Bezzaza <ryan.chappelle@xxxxxxxx>
  • To: dokuwiki@xxxxxxxxxxxxx
  • Date: Wed, 08 Dec 2010 20:17:59 -0300

Håkan Sandell escribió:
> Luis Machuca Bezzaza wrote:
>> Mind a discussion of the i18n'n strategy?
> 
> Not at all ;-)
> 
> I agree that translations should "feel" normal, i.e. to some extent
> supported by core functions rather than relying on developers
> overriding functions. This makes it possible for more
> (non-programming) people to expand the DokuWiki universe.
> 
> But...
> 
> 1. Even if there are translations available the info.txt file should
> have the English description, only a $desc keyword would prohibit
> future uses of this file, related to plugin/template management by
> automated scripts.
> 
1.- Fully agree. I just chose the strategy to have a showable hack quickly.
I'd rather have an enumeration field in plugin.info.txt indicating which
other fields are available for translation, for example[1]. Having an
enumeration field allows for better customization, keeps the code cleaner
and, IINM, might be fully backwards-compatible.

An enumeration field would look like this (where, of course, the actual
naming for the keyword is tentative):

----
name      nifty plugin
desc      Base English description
url       http://www.dokuwiki.org/plugin:nifty4dokuwiki
translate name,desc
----


> 2. Do you have any thought on how to handle different descriptions for
> plugins with several syntax components? Some plugins (tooltip) use
> this and others (data) doesn't. At the moment, the info.txt framework
> doesn't support this but I'm not sure it's necessary.
> 
2.- Of course I have, but it's even hackisher than before ;) -- after all,
tooltip is my devel, so I did some testing with it before throwing myself to
the fire.

Basically, the default strategy would be the same as current: leaving the
text field alone but automatically detecting the presence of alternative
components and appending a "[%s component]" to each one once the
name/description is loaded, where the word "component" may be replaced by a
localized form as well.

Users who want to override the component names for each part of their plugin
might be better overriding getInfo() locally, but since all that effort is
only to add one (two?) strings to the array and the purpose is precisely to
separate internationalization from code programming, a far less error-prone
approach would be to have a "keyword set"
<$lang['plugindesc_componentname']> which is parsed and to which the same
strategy of "fall back to a valid English expression if not overriden" is
applied at the time the localization is found. To make sure it makes sense
in the context, component name/desc localizations should be allowed/parsed
"if and only if" the base localizations have been found as well.

The form for the tooltip plugin, english language file, would look like this
for example:

----
$lang['plugindesc_tooltip'] = 'Provide tooltips in your DokuWiki syntax';
$lang['plugindesc_short']   = 'Mark a single word with a tooltip';
----

I'm not too sure that for this particular case the implementation effort
will be worth it in terms of spread of localization however, since at the
time an user is watching the Plugin Manager for info on the individual
plugins the more likely questions are 1.- how to update (for which there is
"update" button) and 2.- how to use the syntax (for which the DokuWiki site
exists). That, and unless the plugin components are widely known by
themselves (as happens with tag[2] for example), the component localizations
 will become more like a blink-and-you-miss-it, One Scene Wonder.

Would love to be proven wrong on this tho.


> 3. You haven't suggested it and I vote against it, but some plugins
> have translations of the plugin name. Maybe this is great if we should
> write a generic syntax helper/wizard for the editor AND the plugin
> names had good descriptive names.
> 
I don't know of much or even //few// software, let alone plugins, that
change name in localizations. DokuWiki is still DokuWiki in spanish, and I
guess in German too. I'm kind of split on this one. Would be good to have
for consistency though in that it makes plugins better searchable in the new
database, but right now that would be it and only for languages with
drastically different alphabets such as Chinese(s).

> 4. Reading the first post I thought about using the same work flow
> that is used by admin plugins in the getMenuText() function. The
> lang['menu'] has a special meaning, and if entered, auto-magically
> used. Problem is that both 'desc' and 'description' are already used
> by some plugins in other situations.
> 
If another keyword that uniquely identifies plugins can be used all goes
away, and we have still a large assortment of ASCII-7 combinations to come
up with. Why not 'plugin_desc' as in (2)? Betcha no one is using it yet!

> 5. A somewhat related OO-thought: shouldn't syntax.php use composition
> to avoid duplicated code from plugin.php ?
> 
That's what I was surprised //not// to find. The loading code is essentially
the same along all four files (plugin.php and all specializations in
lib/plugins/). Sounds like a matter for another conversation though...


I appreciate the time taken to discuss the issue, considering that for being
the person who brought it to attention I'm not as active as I should be.

As I said in my initial post, I'd appreciate input from other international
DW / plugin developers.

Greetings all.

[1] Not like anyone is to override url or date anyway... right?
[2] http://www.dokuwiki.org/plugin:tag



-- 
----
Luis Machuca Bezzaza
Secretario (S) GULIX - Grupo de Usuarios de GNU/Linux de la IX Región
http://www.gulix.cl/
----

-- 
DokuWiki mailing list - more info at
http://www.dokuwiki.org/mailinglist

Other related posts: