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 634B1D6E2 for ; Fri, 2 Nov 2012 12:00:50 +0000 (UTC) Received: (qmail 23453 invoked by uid 500); 2 Nov 2012 12:00:50 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 23197 invoked by uid 500); 2 Nov 2012 12:00:49 -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 23173 invoked by uid 99); 2 Nov 2012 12:00:49 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Nov 2012 12:00:49 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jancasacondor@gmail.com designates 209.85.214.175 as permitted sender) Received: from [209.85.214.175] (HELO mail-ob0-f175.google.com) (209.85.214.175) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Nov 2012 12:00:43 +0000 Received: by mail-ob0-f175.google.com with SMTP id eq6so3437587obc.6 for ; Fri, 02 Nov 2012 05:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HBRxZmoIAix7haMF6QKh8kg2Zci3o1sNYQCS6rZfwz0=; b=xYN7H1WlfwR3J1yIojUc3x38utq1H8BU5RiFI6v7xzQ1BE2AHTgOgKTmlMTWsyId8g gLEnvpTnm5XGhkAQJF67yb6NPAADBibQQj4E72sojZ0mk/OmVbkjw/Hrh+9TYlB5z1WF wMpkgKDTSCDmfjt8OLWOYB2qmSpwx9I5X7XUZTgc1uUSZievHfbddYwGzkT9Cv3JHdtS QYlrGJdD6nxZPfak+0Yl7NSiDKs53yZ3XBMsoP1AvNfrLQG+qimEYGauFLs0lGVyGOrI anifc981aTTNRfgNQygTj+3yfVrYeY1QAT3pojSNRCi6XI0f0qKgzY4YfDwws1D1LHIi ocNw== MIME-Version: 1.0 Received: by 10.60.1.164 with SMTP id 4mr1117970oen.96.1351857621559; Fri, 02 Nov 2012 05:00:21 -0700 (PDT) Received: by 10.76.91.9 with HTTP; Fri, 2 Nov 2012 05:00:21 -0700 (PDT) In-Reply-To: <5093A9FC.6040701@wtnet.de> References: <508B15AA.20607@wtnet.de> <5091B6AB.8090503@wtnet.de> <50922A40.2060707@gmail.com> <5092DA84.9080103@wtnet.de> <5093A9FC.6040701@wtnet.de> Date: Fri, 2 Nov 2012 13:00:21 +0100 Message-ID: Subject: Re: extensions and translations. From: jan iversen To: ooo-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=e89a8fb1ffe251e81804cd81e176 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8fb1ffe251e81804cd81e176 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +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 ? > > > 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 softwar= e > 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 the= y > 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 com= e > into the AOO project with all the things needed (source grant, signed ICL= A, > 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) wrote: >> >> Am 11/01/2012 01:17 PM, schrieb Rob Weir: >>> >>> On Thu, Nov 1, 2012 at 3:52 AM, J=FCrgen 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 unde= r >>>>> ALv2 and want to contribute the code to the project. We can easy crea= te >>>>> 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 extension= s. >>> >>>> >>>>>> But maybe others here have a great idea? >>>>>> >>>>>> >>>>> we can't probably provide it and I think we have to do enough ;-). Bu= t >>>>> I >>>>> can think of an alternative service hosted somewhere else. >>>>> >>>>> Juergen >>>>> >>>>> >>>>> Or should we just say extension developers does not concern us (an= d >>>>>> >>>>>>> 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 translatio= n, >>>>>>>> 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. A= nd >>>>>>>> therefore they are allowed to (or have to ;-) ) do all on their ow= n; >>>>>>>> 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 yo= u >>>>>>>> for >>>>>>>> doing this task. >>>>>>>> >>>>>>>> Marcus >>>>>>>> >>>>>>> --e89a8fb1ffe251e81804cd81e176--