On Tuesday 09 June 2009 16:20:21 Luke771 wrote: > > Plugins authors: please make the plugins interfaces localized. Currently > non-english l10n users have languages mixing up in fproxy, which looks > horrible and creates usability problems (we want Freenet to become > popular even among people who never bothered to learn Engish) > > It would be a good idea to make the plugins l10n strings available in > the /translation page anyway, no matter what plugins are currently > loaded. This would allow translators to send updates for everything > without having to load plugins they wouldn;t load normally.
I'm not sure that's a good idea. But certainly it should integrate to the translation page if it is loaded. I wonder if the reason this hasn't happened is that we need to provide infrastructure for it? What exactly do we need to do to get the plugins easily translateable? First, some plugins will be unofficial, clearly they will have to provide their own translations, so that must be possible (and easy!). The question is whether official plugins should have their l10n integrated into the main l10n files. I am not convinced. Anyway, the proposal (the interfaces will allow different implementations, of course): - Each plugin would have its own L10n, which inherits from the main L10n. - The plugin's local l10n files would be kept in the plugin, and we would tell the local L10n where they are (probably just by telling it the plugin name, so they will be in plugins/name/l10n). - This can then be used exactly as we use L10n in the node's code, but importing a different L10n class. - The sub-l10n would get a callback when the node language changes, possibly through the existing FredPluginL10n interface. - Likewise when constructing menus, we callback to the plugin to lookup the strings. - We will need new callbacks for the translation page to fetch the strings for the plugin. - We will need a new l10n file format which separates the various plugins and the main node's strings .. probably by prefixing the strings for the plugin with "plugins.name.". - We will need a tool to separate the updates for the main node and the various plugins, and apply them separately. IMHO this is important for 0.8 given we will have Freetalk integrated, but it is not important for 0.7.5, since XMLSpider is the only official plugin with its own submenu. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090610/ae3c859a/attachment.pgp>
