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)<marcus.m...@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<jogischm...@gmail.com>
wrote:
On 11/1/12 12:39 AM, Marcus (OOo) wrote:
Am 10/27/2012 01:17 AM, schrieb jan iversen:
I see, I have to get used to this license issues (a long time ago I
believed open source was just open source, then I joined an apache
project).
never mind.
Would it be to our advantage if we offered third party developers
(that is
how I see extension developers) the possibility to register a
language
file
and get it translated as part of the language packs ?
Of course it would be to our advantage; or let's say for the
project and
software. A lot of extensions would be available in many languages.
However, I don't know where we should draw the line to set a
limit. When
we select here and there some extensions, then the other
developers will
ask why not their extensions.
It's quite simple I would say, if people want develop extensions
under
ALv2 and want to contribute the code to the project. We can easy
create
a special section in our repo where we can host them.
But this means they have to be handled in the same way as all other
stuff here. Means a new release have to be voted...
+1
I think the important thing is this: We don't just want code. We
want communities. So if an extension author thinks that their
extension is generally useful and he/she wants to join the AOO
community and work on the extension here, and allow others to work on
it as well, then this is good.
Of course, +1.
We can have a set of "standard extensions".
So, we just need to define the standard.
Marcus
And IMHO it's not possible to translate all strings for all extensions.
But maybe others here have a great idea?
we can't probably provide it and I think we have to do enough ;-).
But I
can think of an alternative service hosted somewhere else.
Juergen
Or should we just say extension developers does not concern us (and
help
AOO get more used) so we just look the other way ?
Maybe the right way is somewhere in the middle.
Yeah, maybe. ;-)
Marcus
On 27 October 2012 00:58, Marcus (OOo)<marcus.m...@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
