Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B8D84D959 for ; Fri, 2 Nov 2012 13:30:47 +0000 (UTC) Received: (qmail 51805 invoked by uid 500); 2 Nov 2012 13:30:47 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 51593 invoked by uid 500); 2 Nov 2012 13:30:46 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 51570 invoked by uid 99); 2 Nov 2012 13:30:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Nov 2012 13:30:46 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of marcus.mail@wtnet.de designates 213.209.103.3 as permitted sender) Received: from [213.209.103.3] (HELO smtp1.wtnet.de) (213.209.103.3) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Nov 2012 13:30:41 +0000 X-WT-Originating-IP: 84.46.110.107 Received: from f9.linux (pop8-1636.catv.wtnet.de [84.46.110.107]) (authenticated bits=0) by smtp1.wtnet.de (8.14.4/8.14.4) with ESMTP id qA2DUKNQ004777 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 2 Nov 2012 14:30:21 +0100 Message-ID: <5093CAEA.5060503@wtnet.de> Date: Fri, 02 Nov 2012 14:30:18 +0100 From: "Marcus (OOo)" User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: ooo-dev@incubator.apache.org Subject: Re: extensions and translations. References: <508B15AA.20607@wtnet.de> <5091B6AB.8090503@wtnet.de> <50922A40.2060707@gmail.com> <5092DA84.9080103@wtnet.de> <5093A9FC.6040701@wtnet.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org 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) 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) wrote: >>> >>> Am 11/01/2012 01:17 PM, schrieb Rob Weir: >>>> >>>> On Thu, Nov 1, 2012 at 3:52 AM, J�rgen Schmidt >>>> >>>>> 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) >>>>>>> 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/ >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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>>>>>>>> openoffice.org> >>>>>>>>> >>>>>>>> extensions.services.**openoffice.org >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> - >>>>>>>>> http://templates.services.****op**enoffice.org>>>>>>>> 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