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 6CDFED0B2 for ; Thu, 1 Nov 2012 21:07:33 +0000 (UTC) Received: (qmail 31833 invoked by uid 500); 1 Nov 2012 21:07:33 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 31774 invoked by uid 500); 1 Nov 2012 21:07:32 -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 31765 invoked by uid 99); 1 Nov 2012 21:07:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2012 21:07:32 +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.219.47 as permitted sender) Received: from [209.85.219.47] (HELO mail-oa0-f47.google.com) (209.85.219.47) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2012 21:07:26 +0000 Received: by mail-oa0-f47.google.com with SMTP id h1so2976948oag.6 for ; Thu, 01 Nov 2012 14:07:05 -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=NTesECtsmEx5rZiWS9kOquciamiK5RPFQ7/U8HudCNU=; b=G0SJ00iSus+6Vz7xV0LyuCUGWjOFpA3PX47vWos2sMIY2R44yYhHSRAv50Qfe4MzEX sQLTxjK4rOff+PjIJTe6y8BZCACTdMKmYMMUr/6YawGL5du/AJCYvMRcGbF15tAeE8hB AkNtjtLEC0DkIemByEyzP/Nm3hOI/wvNJ8+6TTosmIdsYU8O8TAUDP8f10yX9H37AM/y Wd/UnXyTGKZRJCnkleODQCFcXdz2WduxWDF6BGXjI5gnLmpiRuNJoGUd98JwlJDk19fT 4xGv7sfwEMkdPM5h0mAqbxmWGtS0A9ArKlxYn+8M8Nqq01MV12BThY6r8xsssHipfa0y KZGg== MIME-Version: 1.0 Received: by 10.60.13.132 with SMTP id h4mr4235882oec.72.1351804025288; Thu, 01 Nov 2012 14:07:05 -0700 (PDT) Received: by 10.76.91.9 with HTTP; Thu, 1 Nov 2012 14:07:05 -0700 (PDT) In-Reply-To: <5092DA84.9080103@wtnet.de> References: <508B15AA.20607@wtnet.de> <5091B6AB.8090503@wtnet.de> <50922A40.2060707@gmail.com> <5092DA84.9080103@wtnet.de> Date: Thu, 1 Nov 2012 22:07:05 +0100 Message-ID: Subject: Re: extensions and translations. From: jan iversen To: ooo-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=e89a8fb20418bbb75a04cd7566d9 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8fb20418bbb75a04cd7566d9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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) 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 languag= e >>>>> 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 a= nd >>>> 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. Wh= en >>>> we select here and there some extensions, then the other developers wi= ll >>>> 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 slig= ht >>>>>> >>>>>>> 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 "buil= d >>>>>> --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://templates.services.**op**enoffice.org = < >>>>>> http://templates.**services.openoffice.org >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> I might be following a wrong track here, but please forgive me fo= r >>>>>> 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 fo= r >>>>>> doing this task. >>>>>> >>>>>> Marcus >>>>>> >>>>> --e89a8fb20418bbb75a04cd7566d9--