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