Re: [Gramps-devel] Third-party plugins

[Doug B. <dou...@gm...>]

On Tue, Oct 27, 2009 at 8:26 AM, Benny Malengier
<ben...@gm...> wrote:
> 2009/10/27 Doug Blank <dou...@gm...>:
>> On Tue, Oct 27, 2009 at 7:40 AM, Benny Malengier
>> <ben...@gm...> wrote:
>>> 2009/10/27 Doug Blank <dou...@gm...>:
>>>> Developers,
>>>>
>>>> A few ideas I'd like to bounce off of you:
>>>>
>>>> 1) There are developers that work in gramps SVN, but that also have
>>>> third-party contributions. I think many of those contributions live
>>>> outside of our SVN, but there isn't really a reason why they must
>>>> (right?). What if we had a src/plugins/contrib subdirectory in SVN
>>>> where that code could be worked on in subdirs. It could also be
>>>> packaged there (zipped file of .gpr.py and all necessary files). Then
>>>> the plugin page could just point to the SVN repository.
>>>
>>> I think a separate repository should be made, so that users who have
>>> access to that one, do not need access to the GRAMPS repo.
>>
>> Yes, that is a better idea. Limit the access to just those plugins.
>>
>>>> 2) How do plugins in other projects handle translations? Is there an
>>>> easy manner for shipping additional translation files with a plugin,
>>>> and installing them? If not, I was thinking of an API for us to allow
>>>> plugins to augment our current setup.
>>>
>>> This is a problem. The nicest would be to have translation inside of
>>> the gramps.pot, but not possible with another repository. So the
>>> solution would be to use for plugins a translation domain
>>> grampsplugins, and have contributed plugins use _() function binded to
>>> the domain grampsplugins.
>>> For translators this should not be an issue, on translating
>>> grampsplugins.pot, they can first use gramps.pot to translate
>>> everything that is already present in the gramps module, then
>>> translate only the missing strings. Tools like kbabel can work with
>>> dictionaries making it even more simple.
>>
>> But this would only work for those plugins that are in this new
>> proposed plugin repository, right? We could do that, but what about
>> others? Or would we require plugins to come from our contrib
>> repository?
>
> Translation is difficult, no matter how we do it. The plugin author
> himself cannot do it because he does not know the other languages.

No, but an author can have people add their translations to the
plugin's local translation files (in gettext format, or something
else). I'm thinking of a distributed gettext-based system.

> Using a repo that plugin authors can request access too, makes it easy
> for non coders to translate third party plugins.
> The plugin must follow the concept of module translation:
> http://docs.python.org/library/gettext.html#localizing-your-module so
> no changes to the global gettext instance may be done (as that would
> change the language of gramps and grampsplugin does not contain those
> strings)
> Plugins outside of that system can only be translated if they set up
> their own translation via gettext class, and distribute the necessary
> .mo files.
>
> On a release of gramps we could also release a grampsplugins.mo taken
> from the third party plugins.
>
> Note that I see the class based api has an add_fallback function to
> add a fallback translation domain, so we might be able to globally
> define to use gramps.mo, and if not found grampsplugins.mo.

What class api are you referring? If there was a way for each addon
plugin to add their own local fallback translations, that would work.
If you know of a tutorial or docs on such things for gettext that
would be useful for me.

>> I was thinking of a way of having dynamic translations in the plugin,
>> if something wasn't in the po file.
>
> Not a good idea. We need to use the gettext system, it simplifies
> things a lot not to have to care.

Right, I'm only thinking of building on gettext. But perhaps gettext
has something like this already.

-Doug

>>>> 3) What about creating a new extension for our plugins (perhaps
>>>> .gplug) and a mime-type, so that we could load them, and humans would
>>>> recognize what they are?
>>>
>>> You mean for the tar file with plugin in it? Yes, that is an option.
>>> See http://live.gnome.org/Gedit/PythonPluginHowTo , so perhaps
>>> gramps-plugin as extension.
>>
>> That file (.gedit-plugin) looks like just the definition file (our
>> .gpr.py file).
>>
>> Perhaps "plugin" is not a good outward facing name for Uncle Bob (Aunt
>> Martha's new boyfriend). Looks like Firefox calls all additional items
>> "add-ons", and "plugin" is a type of "add-on" (among "extension",
>> "themes", and "languages").
>>
>> So, maybe .gramps-addon?
>
> I have no preference myself.
>
> Benny
>>
>> -Doug
>>
>>> Benny
>>>
>>
>