On Wednesday 10 June 2009 17:01:43 Matthew Toseland wrote:
> 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.
>
Nextgens has pointed out that this is going to make it harder to build a proper
plugin API with no shared code and only interfaces. Any suggestions for how to
make this easy for plugins without them having to inherit classes from Freenet
itself?
-------------- 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/79c09db8/attachment.pgp>
