openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan iversen <jancasacon...@gmail.com>
Subject Re: extensions and translations.
Date Fri, 02 Nov 2012 12:00:21 GMT
+1 to your ideas, much better formulated than mine.

see below for comments.

Jan

On 2 November 2012 12:09, Marcus (OOo) <marcus.mail@wtnet.de> wrote:

> Am 11/01/2012 10:07 PM, schrieb jan iversen:
>
>  Can "standard" loosely be defined as an extension:
>> - is developed by people who have signed ICLA
>> - uses the apache license header in the source files
>>
>
> It's indeed important but IMHO this shouldn't be part of the decision to
> draw the standard as it's about formal and general things.
>
>
>  - is of interest to the general public in different countries
>>
>
> Absolute.
>
>
>  - is willing to let the source be controlled/reviewed by committer.
>>
>
> With the possibility to become a committer later-on.
>
>
>  - accept a vote by the committers to be accepted
>>
>
> If a code grant is necessary depends maybe a bit on the amount of the
> extension source code.

+1, but having the option of a vote is not bad...I did not want to write
"accept that a committer can veto the change".

>
>
>  If those points are fuillfilled we could add the project to "swext", and
>> then it would automatically be integrated in the build and l10n process.
>>
>
> Is "swext" only for extension around AOO Writer or general? If for Writer
> then it should be located in a different, own directory within the source
> code.

At least Wiki publisher attaches only to writer. What do you mean "within
the source code", is main/swext not within ?

>
>
>  Please help me out here, I am not sure if that is enough for the "apache
>> way".
>>
>
> I would suggest to define the standard around some factors. Some thoughts:
>
> - What is the benefit for AOO?
>
This might be a bit problematic, who is to judge it.

> - Is this helful for the general public or only for specific users?
>
+1

> - Does it exchange existing functionality with something own?
>
+1

> - What are the usage numbers / review comments look like?
>
If I understand it correct, you see the extension first in the usual
extensions place, and then it can "grow" into AOO ?
Would there not be cases, where it was developed directly within AOO.

> - How big is the extension (keep in mind we shouldn't blow-up our software
> too excessive).
>
Is that not more a problem of release packaging ?
We could put the extensions in an own installation, like language packs.

> - Don't install the extension by default but let the user decide what they
> want, then make 1-3 wizard pages in the installer only for installing
> extensions
>
+1

>
> Of course this can only work if the extension developer is willing to come
> into the AOO project with all the things needed (source grant, signed ICLA,
> header change, voting for releases, etc.).
>
+1 that is important, extensions integrated in the source must obey the
same rules as all other source code.

>
> Marcus
>
>
>
>  On 1 November 2012 21:24, Marcus (OOo)<marcus.mail@wtnet.de>  wrote:
>>
>>  Am 11/01/2012 01:17 PM, schrieb Rob Weir:
>>>
>>>   On Thu, Nov 1, 2012 at 3:52 AM, J├╝rgen Schmidt<jogischmidt@gmail.com>
>>>
>>>>   wrote:
>>>>
>>>>  On 11/1/12 12:39 AM, Marcus (OOo) wrote:
>>>>>
>>>>>  Am 10/27/2012 01:17 AM, schrieb jan iversen:
>>>>>>
>>>>>>  I see, I have to get used to this license issues (a long time ago
I
>>>>>>> believed open source was just open source, then I joined an apache
>>>>>>> project).
>>>>>>>
>>>>>>> never mind.
>>>>>>>
>>>>>>> Would it be to our advantage if we offered third party developers
>>>>>>> (that is
>>>>>>> how I see extension developers) the possibility to register a
>>>>>>> language
>>>>>>> file
>>>>>>> and get it translated as part of the language packs ?
>>>>>>>
>>>>>>>
>>>>>> Of course it would be to our advantage; or let's say for the project
>>>>>> and
>>>>>> software. A lot of extensions would be available in many languages.
>>>>>>
>>>>>> However, I don't know where we should draw the line to set a limit.
>>>>>> When
>>>>>> we select here and there some extensions, then the other developers
>>>>>> will
>>>>>> ask why not their extensions.
>>>>>>
>>>>>>
>>>>> It's quite simple I would say, if people want develop extensions under
>>>>> ALv2 and want to contribute the code to the project. We can easy create
>>>>> a special section in our repo where we can host them.
>>>>>
>>>>> But this means they have to be handled in the same way as all other
>>>>> stuff here. Means a new release have to be voted...
>>>>>
>>>>>
>>>>>
>>>> +1
>>>>
>>>> I think the important thing is this:  We don't just want code.  We
>>>> want communities.  So if an extension author thinks that their
>>>> extension is generally useful and he/she wants to join the AOO
>>>> community and work on the extension here, and allow others to work on
>>>> it as well, then this is good.
>>>>
>>>>
>>> Of course, +1.
>>>
>>>
>>>   We can have a set of "standard extensions".
>>>
>>>>
>>>>
>>> So, we just need to define the standard.
>>>
>>> Marcus
>>>
>>>
>>>
>>>
>>>   And IMHO it's not possible to translate all strings for all extensions.
>>>
>>>>
>>>>>> But maybe others here have a great idea?
>>>>>>
>>>>>>
>>>>> we can't probably provide it and I think we have to do enough ;-). But
>>>>> I
>>>>> can think of an alternative service hosted somewhere else.
>>>>>
>>>>> Juergen
>>>>>
>>>>>
>>>>>    Or should we just say extension developers does not concern us (and
>>>>>>
>>>>>>> help
>>>>>>> AOO get more used) so we just look the other way ?
>>>>>>>
>>>>>>> Maybe the right way is somewhere in the middle.
>>>>>>>
>>>>>>>
>>>>>> Yeah, maybe. ;-)
>>>>>>
>>>>>> Marcus
>>>>>>
>>>>>>
>>>>>>
>>>>>>   On 27 October 2012 00:58, Marcus (OOo)<marcus.mail@wtnet.de>
>>>>>>  wrote:
>>>>>>
>>>>>>>
>>>>>>>   Am 10/27/2012 12:36 AM, schrieb jan iversen:
>>>>>>>
>>>>>>>>
>>>>>>>>     While doing an update to the l10n workflow I think I
found a
>>>>>>>> slight
>>>>>>>>
>>>>>>>>  problem.
>>>>>>>>>
>>>>>>>>> Extensions offers the capability to integrate/extend
our UI.
>>>>>>>>>
>>>>>>>>> Assuming somebody writes an extension, and publishes
it on
>>>>>>>>> http://www.openoffice.org/******extensions/<http://www.openoffice.org/****extensions/>
>>>>>>>>> <http://www.**openoffice.org/**extensions/<http://www.openoffice.org/**extensions/>
>>>>>>>>> >
>>>>>>>>> <http://www.**openoffice.org/**extensions/<http://openoffice.org/extensions/>
>>>>>>>>> <http://www.**openoffice.org/extensions/<http://www.openoffice.org/extensions/>
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>  how
>>>>>>>>>>
>>>>>>>>> does that get integrated into the
>>>>>>>>> translation process ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  Simply, not at all.
>>>>>>>>
>>>>>>>>
>>>>>>>>     As far as I can see the sources are not integrated into
our
>>>>>>>> "build
>>>>>>>> --all
>>>>>>>>
>>>>>>>>  --with-lang".
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  Right.
>>>>>>>>
>>>>>>>>
>>>>>>>>     If I am right that they are not part of the general translation,
>>>>>>>> then is
>>>>>>>>
>>>>>>>>  that per design so or should it be different ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  Yes, this is by design.
>>>>>>>>
>>>>>>>> Extensions are offered to extent your AOO install at any
point of
>>>>>>>> time.
>>>>>>>> These are developed by people that do not have to belong
to our
>>>>>>>> project
>>>>>>>> (when we put aside some exceptions). They can act independently.
And
>>>>>>>> therefore they are allowed to (or have to ;-) ) do all on
their own;
>>>>>>>> incl.
>>>>>>>> translation.
>>>>>>>>
>>>>>>>> That applies for all extensions and templates available on:
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://extensions.services.****o**penoffice.org<http://**
>>>>>>>> openoffice.org <http://openoffice.org>>
>>>>>>>> <http://**extensions.services.****openoffice.org<http://**
>>>>>>>> extensions.services.**openoffice.org<http://extensions.services.openoffice.org>
>>>>>>>> >
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> -
>>>>>>>> http://templates.services.****op**enoffice.org<http://**
>>>>>>>> openoffice.org <http://openoffice.org>><
>>>>>>>> http://templates.**services.**openoffice.org<http://services.openoffice.org>
>>>>>>>> <http://**templates.services.openoffice.**org<http://templates.services.openoffice.org>
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     I might be following a wrong track here, but please forgive
me
>>>>>>>> for
>>>>>>>> trying
>>>>>>>>
>>>>>>>>  to make the l10n process as complete as I can.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  Don't panic. That's a great goal and everybody is thankful
to you
>>>>>>>> for
>>>>>>>> doing this task.
>>>>>>>>
>>>>>>>> Marcus
>>>>>>>>
>>>>>>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message