You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by jan iversen <ja...@gmail.com> on 2012/10/27 00:36:38 UTC
extensions and translations.
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/ how does that get integrated into the
translation process ?
As far as I can see the sources are not integrated into our "build --all
--with-lang".
If I am right that they are not part of the general translation, then is
that per design so or should it be different ?
I might be following a wrong track here, but please forgive me for trying
to make the l10n process as complete as I can.
rgds
Jan I.
Re: extensions and translations.
Posted by jan iversen <ja...@gmail.com>.
+1 agree....
how can we get it operational, we already have a swext directory,
containing wiki publisher, should we encourage people to use that, or do we
want to some kind of filter approach, to what is standard extensions ?
Jan.
On 1 November 2012 14:31, Roberto Galoppini <rg...@geek.net> wrote:
> On Thu, Nov 1, 2012 at 1:17 PM, Rob Weir <ro...@apache.org> wrote:
>
> > On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidt <jo...@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. We can have a set of "standard
> > extensions".
> >
>
> Agree 100%.
>
> Roberto
>
>
> >
> > >>
> > >> 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)<ma...@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/>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.**openoffice.org<
> > http://extensions.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
> > >
> >
>
> --
> ====
> This e- mail message is intended only for the named recipient(s) above. It
> may contain confidential and privileged information. If you are not the
> intended recipient you are hereby notified that any dissemination,
> distribution or copying of this e-mail and any attachment(s) is strictly
> prohibited. If you have received this e-mail in error, please immediately
> notify the sender by replying to this e-mail and delete the message and any
> attachment(s) from your system. Thank you.
>
>
Re: extensions and translations.
Posted by Roberto Galoppini <rg...@geek.net>.
On Thu, Nov 1, 2012 at 1:17 PM, Rob Weir <ro...@apache.org> wrote:
> On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidt <jo...@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. We can have a set of "standard
> extensions".
>
Agree 100%.
Roberto
>
> >>
> >> 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)<ma...@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/>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.**openoffice.org<
> http://extensions.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
> >
>
--
====
This e- mail message is intended only for the named recipient(s) above. It
may contain confidential and privileged information. If you are not the
intended recipient you are hereby notified that any dissemination,
distribution or copying of this e-mail and any attachment(s) is strictly
prohibited. If you have received this e-mail in error, please immediately
notify the sender by replying to this e-mail and delete the message and any
attachment(s) from your system. Thank you.
Re: extensions and translations.
Posted by Andrea Pescetti <pe...@apache.org>.
jan iversen wrote:
> On 1 November 2012 22:21, Rob Weir wrote:
>> 2) An extension that is developed and released by the project, and
>> published in the extension repository.
> This is the current standard and should not be changed. the add on is
> optional
Indeed.
> and not to forget, the possibility of getting the UI translated and
> available all over the world.
In general this discussion is probably making too many assumptions on
the extensions authors. Those who wanted translatable extensions had a
sort of framework to put string in PO files (which I never used and
which I remember very vaguely, but it only worked for StarBasic); and as
far as I know it was very rarely used. In general, remember that an
extension can be written in any language, including no language (there
is plenty of non-code extensions
http://wiki.openoffice.org/wiki/Non-code_extensions ); so extracting
strings or enforcing coherence will work optimally only for extensions
that are developed by the project.
> Can we collect statistics about which extensions is installed how often ?
http://extensions.openoffice.org/en/most_popular
The "timeline" gives you all details.
Regards,
Andrea.
Re: extensions and translations.
Posted by jan iversen <ja...@gmail.com>.
see below please.
On 1 November 2012 22:21, Rob Weir <ro...@apache.org> wrote:
> On Thu, Nov 1, 2012 at 5:07 PM, jan iversen <ja...@gmail.com>
> wrote:
> > 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
> > - is of interest to the general public in different countries
> > - is willing to let the source be controlled/reviewed by committer.
> > - accept a vote by the committers to be accepted
> >
> > 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.
> >
> > Please help me out here, I am not sure if that is enough for the "apache
> > way".
> >
>
> There are probably two degrees of "standard" or "official" extensions.
>
> 1) An extension that is released with our binaries, e.g., it is
> available "out-of-the-box", either automatically installed, or
> available as an option in the installer.
>
That would be things like "wiki publisher" in swext, that still have the
sun license and not the apache license.
But that what actually what I was thinking about, and of course these
extension MUST be part of the apache demands.
We might include include in the setup package, but it should not be
automatically installed, if that was the case the end-user would see it as
an integrated part, and not an add-on. We should not take responsibility
for the extension, but simply offer it.
> 2) An extension that is developed and released by the project, and
> published in the extension repository.
>
This is the current standard and should not be changed. the add on is
optional
>
> The process for these would be nearly identical, differing only on
> whether it is released standalone or bundled with the full AOO
> installer.
>
and not to forget, the possibility of getting the UI translated and
available all over the world.
Can we collect statistics about which extensions is installed how often ??
>
> -Rob
>
> > Jan.
> >
> >
> > On 1 November 2012 21:24, Marcus (OOo) <ma...@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<jo...@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)<ma...@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/>
> >>>>>>>> >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://**extensions.services.**openoffice.org<
> http://extensions.services.openoffice.org>
> >>>>>>> >
> >>>>>>>
> >>>>>>> -
> >>>>>>> http://templates.services.**op**enoffice.org <
> http://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
> >>>>>>>
> >>>>>>
>
Re: extensions and translations.
Posted by Rob Weir <ro...@apache.org>.
On Thu, Nov 1, 2012 at 5:07 PM, jan iversen <ja...@gmail.com> wrote:
> 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
> - is of interest to the general public in different countries
> - is willing to let the source be controlled/reviewed by committer.
> - accept a vote by the committers to be accepted
>
> 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.
>
> Please help me out here, I am not sure if that is enough for the "apache
> way".
>
There are probably two degrees of "standard" or "official" extensions.
1) An extension that is released with our binaries, e.g., it is
available "out-of-the-box", either automatically installed, or
available as an option in the installer.
2) An extension that is developed and released by the project, and
published in the extension repository.
The process for these would be nearly identical, differing only on
whether it is released standalone or bundled with the full AOO
installer.
-Rob
> Jan.
>
>
> On 1 November 2012 21:24, Marcus (OOo) <ma...@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<jo...@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)<ma...@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/>
>>>>>>>> >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://**extensions.services.**openoffice.org<http://extensions.services.openoffice.org>
>>>>>>> >
>>>>>>>
>>>>>>> -
>>>>>>> http://templates.services.**op**enoffice.org <http://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
>>>>>>>
>>>>>>
Re: extensions and translations.
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 11/02/2012 02:02 PM, schrieb Andre Fischer:
> On 02.11.2012 12:09, Marcus (OOo) 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.
>>
>>> 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.
>
> I think that is up to the author of an extension to put it in the AOO
> source repository.
> It is up to the community to decide whether to include it in a release.
>
>>
>> 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.
>
> Only for Writer.
>
> I know of at least three directories for extensions:
>
> swext/
> sdext/
> extensions/
>
> I created sdext myself, back in the days.
> I think we should join the three directories, with extensions/ being the
> natural candidate to remain.
+1
Then there is only one location where to search for extensions. Should
it make more simple in the future, also for new joiners.
Marcus
> By the way, there is no either or for extensions regarding their
> presence in the extension repository or in the SVN repository. Many are
> present in both.
>
> -Andre
>
>>
>>> 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?
>> - Is this helful for the general public or only for specific users?
>> - Does it exchange existing functionality with something own?
>> - What are the usage numbers / review comments look like?
>> - How big is the extension (keep in mind we shouldn't blow-up our
>> software too excessive).
>> - 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
>>
>> 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.).
>>
>> Marcus
>>
>>
>>
>>> On 1 November 2012 21:24, Marcus (OOo)<ma...@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<jo...@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)<ma...@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/>
>>>>>>>>>>
>>>>>>>>>>> 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://**extensions.services.**openoffice.org<http://extensions.services.openoffice.org>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -
>>>>>>>>> http://templates.services.**op**enoffice.org<http://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
Re: extensions and translations.
Posted by Andre Fischer <aw...@gmail.com>.
On 02.11.2012 12:09, Marcus (OOo) 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.
>
>> 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.
I think that is up to the author of an extension to put it in the AOO
source repository.
It is up to the community to decide whether to include it in a release.
>
> 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.
Only for Writer.
I know of at least three directories for extensions:
swext/
sdext/
extensions/
I created sdext myself, back in the days.
I think we should join the three directories, with extensions/ being the
natural candidate to remain.
By the way, there is no either or for extensions regarding their
presence in the extension repository or in the SVN repository. Many are
present in both.
-Andre
>
>> 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?
> - Is this helful for the general public or only for specific users?
> - Does it exchange existing functionality with something own?
> - What are the usage numbers / review comments look like?
> - How big is the extension (keep in mind we shouldn't blow-up our
> software too excessive).
> - 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
>
> 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.).
>
> Marcus
>
>
>
>> On 1 November 2012 21:24, Marcus (OOo)<ma...@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<jo...@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)<ma...@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/>
>>>>>>>>>
>>>>>>>>>> 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://**extensions.services.**openoffice.org<http://extensions.services.openoffice.org>
>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> -
>>>>>>>> http://templates.services.**op**enoffice.org<http://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
Re: extensions and translations.
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 11/02/2012 01:00 PM, schrieb jan iversen:
> +1 to your ideas, much better formulated than mine.
>
> see below for comments.
>
> Jan
>
> On 2 November 2012 12:09, Marcus (OOo)<ma...@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 ?
It is, but I meant "somewhere else in the code structure".
Maybe it's good to put all extension into an own structure. But I don't
know the build system and talking maybe nuts. ;-)
>> 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.
The community. When we want some extensions to be put into the AOO
installer then we have to decide which ones. Of course this should be
done with objective facts and not with thumbs up/down or something else.
If it's implementing a beautiful sidepane where some elements like
navigator, stylist, etc. can be placed then it would be candidate #1.
If it's just adding a menu point to change all TOC items into a
clickable link then this is not enough.
Just to define 2 extremes.
>> - 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 ?
Right.
> Would there not be cases, where it was developed directly within AOO.
Then it would be already within AOO.
There are a few exceptions like the MySQL connector which has still a
GPL license and therefore has to stay outside.
>> - 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 ?
Hm, not really. I assume that the extension will bring in new code and
not mostly redundant code. You will come to a point where you cannot get
more optimazations without to put too much effort into it.
I'm not sure but you should see already a difference in size when
comiling AOO with the extisting extensions (like the Wiki publisher) and
then without any.
> We could put the extensions in an own installation, like language packs.
Yes, some "Best of AOO extensions" compilations would be a nice idea.
>> - 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.
Thanks for your further comments. When we (all of us) can find some more
and come to an agreement, we can setup a definition how to get more
extensions into AOO and their developers into our project.
Marcus
>> On 1 November 2012 21:24, Marcus (OOo)<ma...@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<jo...@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)<ma...@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
Re: extensions and translations.
Posted by jan iversen <ja...@gmail.com>.
+1 to your ideas, much better formulated than mine.
see below for comments.
Jan
On 2 November 2012 12:09, Marcus (OOo) <ma...@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)<ma...@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<jo...@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)<ma...@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
>>>>>>>>
>>>>>>>
Re: extensions and translations.
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
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.
> 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.
> 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?
- Is this helful for the general public or only for specific users?
- Does it exchange existing functionality with something own?
- What are the usage numbers / review comments look like?
- How big is the extension (keep in mind we shouldn't blow-up our
software too excessive).
- 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
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.).
Marcus
> On 1 November 2012 21:24, Marcus (OOo)<ma...@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<jo...@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)<ma...@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/>
>>>>>>>>> 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://**extensions.services.**openoffice.org<http://extensions.services.openoffice.org>
>>>>>>>>
>>>>>>>
>>>>>>> -
>>>>>>> http://templates.services.**op**enoffice.org<http://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
Re: extensions and translations.
Posted by jan iversen <ja...@gmail.com>.
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
- is of interest to the general public in different countries
- is willing to let the source be controlled/reviewed by committer.
- accept a vote by the committers to be accepted
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.
Please help me out here, I am not sure if that is enough for the "apache
way".
Jan.
On 1 November 2012 21:24, Marcus (OOo) <ma...@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<jo...@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)<ma...@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/>
>>>>>>> >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://**extensions.services.**openoffice.org<http://extensions.services.openoffice.org>
>>>>>> >
>>>>>>
>>>>>> -
>>>>>> http://templates.services.**op**enoffice.org <http://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
>>>>>>
>>>>>
Re: extensions and translations.
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 11/01/2012 01:17 PM, schrieb Rob Weir:
> On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidt<jo...@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)<ma...@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/>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.**openoffice.org<http://extensions.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
Re: extensions and translations.
Posted by Rob Weir <ro...@apache.org>.
On Thu, Nov 1, 2012 at 3:52 AM, Jürgen Schmidt <jo...@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. We can have a set of "standard
extensions".
>>
>> 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)<ma...@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/>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.**openoffice.org<http://extensions.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
>
Re: extensions and translations.
Posted by Jürgen Schmidt <jo...@gmail.com>.
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...
>
> 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)<ma...@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/>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.**openoffice.org<http://extensions.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
Re: extensions and translations.
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
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.
And IMHO it's not possible to translate all strings for all extensions.
But maybe others here have a great idea?
> 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)<ma...@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/>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.**openoffice.org<http://extensions.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
Re: extensions and translations.
Posted by jan iversen <ja...@gmail.com>.
Got it, as Marcus explained, this is not a path to follow, but now I can
write in my document that is has been discussed.
jan
On 27 October 2012 14:47, Ariel Constenla-Haile <ar...@apache.org> wrote:
> On Sat, Oct 27, 2012 at 10:27:34AM +0200, jan iversen wrote:
> > I agree with you, we should NOT put a new framework on extensions writer.
> >
> > I was thinking along the lines of
> >
> > make a new directory ./extras/extensions/source, with files <extension
> > name>.<known extension>
>
> This will force the extension developer to release that file under the
> ALv2, because only ALv2 code can be committed.
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>
Re: extensions and translations.
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Sat, Oct 27, 2012 at 10:27:34AM +0200, jan iversen wrote:
> I agree with you, we should NOT put a new framework on extensions writer.
>
> I was thinking along the lines of
>
> make a new directory ./extras/extensions/source, with files <extension
> name>.<known extension>
This will force the extension developer to release that file under the
ALv2, because only ALv2 code can be committed.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: extensions and translations.
Posted by jan iversen <ja...@gmail.com>.
I agree with you, we should NOT put a new framework on extensions writer.
I was thinking along the lines of
make a new directory ./extras/extensions/source, with files <extension
name>.<known extension>
The extension writer must submit the file (we do not collect them) through
a committer.
This directory would then go into the normal l10n workflow, and the
resulting translation would go back into the same directory as <extension
name>.<langugage>.po
jan.
On 27 October 2012 03:53, Ariel Constenla-Haile <ar...@apache.org> wrote:
> On Sat, Oct 27, 2012 at 01:17:33AM +0200, jan iversen wrote:
> > 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).
>
> It has nothing to do with licensing. Even if the extension code and all
> its dependencies are under the ALv2, why should OpenOffice include
> extensions by default in the install set? This goes against the concept
> of an extension.
>
> The fact that now there are three supported extensions is just
> a question of old Sun/Oracle decisions to release these as extension and
> not integrated as part of the application.
>
> >
> > 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 ?
>
> This will break several concepts and things. Mainly extension developers
> have complete freedom about when to release updates, how to integrate
> translation in their extensions (use the configuration API and XCU
> files, use the resource API and Java-property-like files, etc.), most
> important what license to choose, etc.
>
> In short, you will have to implement a new framework and force
> extensions developers to use it. Besides several concerns, legal
> concerns among them.
>
>
> > Or should we just say extension developers does not concern us (and help
> > AOO get more used) so we just look the other way ?
>
> Programmability and extensibility has always been a priority in
> OpenOffice, just read the Developer's Guide and other parts of the wiki.
>
> I tend to agree that it will be useful for an extension developer a way
> to submit a set of resource strings and get them translated, as long as
> the extension developer is not forced with release/legal/other concerns.
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>
Re: extensions and translations.
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 10/27/2012 03:53 AM, schrieb Ariel Constenla-Haile:
> On Sat, Oct 27, 2012 at 01:17:33AM +0200, jan iversen wrote:
>> 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).
>
> It has nothing to do with licensing. Even if the extension code and all
> its dependencies are under the ALv2, why should OpenOffice include
> extensions by default in the install set? This goes against the concept
> of an extension.
>
> The fact that now there are three supported extensions is just
> a question of old Sun/Oracle decisions to release these as extension and
> not integrated as part of the application.
>
>>
>> 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 ?
>
> This will break several concepts and things. Mainly extension developers
> have complete freedom about when to release updates, how to integrate
> translation in their extensions (use the configuration API and XCU
> files, use the resource API and Java-property-like files, etc.), most
> important what license to choose, etc.
Right. Then they are no longer independent from their own release plan
as they may would like to be.
Furthermore, I don't know how many extensions Sourceforge is hosting but
it could hundreads if not thousands. Lets assume 10% of them will say
"yes AOO, please translate the strings for me" then we have a lot more
to do. And who should verify the translations? If we, then we have to
install these hundreads/thousands extensions to see how it's working. If
the developer, then do we get feedback in time? What about errors, are
we able to fix them in time?
I think you can see now that the extension development has it own small
but fine ecosystem. It doesn't fit into the AOO release process and IMHO
this was never the idea.
However, thanks for making these thoughts. :-)
Marcus
> In short, you will have to implement a new framework and force
> extensions developers to use it. Besides several concerns, legal
> concerns among them.
>
>
>> Or should we just say extension developers does not concern us (and help
>> AOO get more used) so we just look the other way ?
>
> Programmability and extensibility has always been a priority in
> OpenOffice, just read the Developer's Guide and other parts of the wiki.
>
> I tend to agree that it will be useful for an extension developer a way
> to submit a set of resource strings and get them translated, as long as
> the extension developer is not forced with release/legal/other concerns.
Re: extensions and translations.
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Sat, Oct 27, 2012 at 01:17:33AM +0200, jan iversen wrote:
> 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).
It has nothing to do with licensing. Even if the extension code and all
its dependencies are under the ALv2, why should OpenOffice include
extensions by default in the install set? This goes against the concept
of an extension.
The fact that now there are three supported extensions is just
a question of old Sun/Oracle decisions to release these as extension and
not integrated as part of the application.
>
> 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 ?
This will break several concepts and things. Mainly extension developers
have complete freedom about when to release updates, how to integrate
translation in their extensions (use the configuration API and XCU
files, use the resource API and Java-property-like files, etc.), most
important what license to choose, etc.
In short, you will have to implement a new framework and force
extensions developers to use it. Besides several concerns, legal
concerns among them.
> Or should we just say extension developers does not concern us (and help
> AOO get more used) so we just look the other way ?
Programmability and extensibility has always been a priority in
OpenOffice, just read the Developer's Guide and other parts of the wiki.
I tend to agree that it will be useful for an extension developer a way
to submit a set of resource strings and get them translated, as long as
the extension developer is not forced with release/legal/other concerns.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: extensions and translations.
Posted by jan iversen <ja...@gmail.com>.
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 ?
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.
jan.
On 27 October 2012 00:58, Marcus (OOo) <ma...@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/>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.**openoffice.org<http://extensions.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
>
Re: extensions and translations.
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
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/ 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.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
Re: extensions and translations.
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Sat, Oct 27, 2012 at 12:36:38AM +0200, jan iversen wrote:
> 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/ how does that get integrated into the
> translation process ?
They don't. They don't belong to OpenOffice source tree. Only the
Presenter Screen, the Presentation Minimizer and the Wiki Publisher are
the currently supported extensions by this Apache project (even though
the versions you find in the extensions site are rather old, the Wiki
Publisher has Sun's name in it!).
The source code for these extensions is located in main/sdext and
main/swext.
The Report Builder (main/reportbuilder), the MySQL SDBC driver
(main/mysqlc) and the PDF Import (main/sdext) extensions are in the
source tree but they can't be released by this Apache Project due to
license conflict in its dependencies. The extension code is under the
ALv2, but the dependencies are copy-left.
All other extensions in the extension site are third party extensions,
with all kind of licenses, and are unrelated to the Apache OpenOffice
project.
> As far as I can see the sources are not integrated into our "build --all
> --with-lang".
Because they are third party extensions.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina