On 11/23/12 5:14 PM, Rory O'Farrell wrote: > On Fri, 23 Nov 2012 17:00:54 +0100 > jan iversen <j...@apache.org> wrote: > >> Good idea, that was basically what I meant...however even microsoft, does >> provide a slim setup, that then downloads the needed packages. > > There is a disadvantage to that: such an installation has to have on-line > access at install time. There are still many users who do not have on-line > access 24/7 at broadband speeds; they may rely for installation on a download > on a public library machine or a friend's machine and transfer the file to > the target computer by USB key, so a complete package (whether compiled for > natice language or as outlined above) would be useful to them, >
we have already thought in such a direction and we have taken offline installation into account as well. But that is much more work and not possible in the near future. But volunteers are welcome to think about it and ideas are welcome. We can only benefit from a smaller download package or a better approach to reuse the main part that is language independent. The only thing we should keep in mind is the 1-click installation user experience. Juergen >> >> jan >> >> On 23 November 2012 16:58, Rory O'Farrell <ofarr...@iol.ie> wrote: >> >>> On Fri, 23 Nov 2012 16:00:38 +0100 >>> jan iversen <j...@apache.org> wrote: >>> >>>> Following your thought... >>>> >>>> Would it not be an idea, if we defined the binary to be en-US always, and >>>> then modify the installation scripts to include the proper language pack >>> ?? >>>> >>>> Please see it as an open question, I do not know if there are other >>>> implications. I have for some time (years) downloaded the en-US binary >>> and >>>> added the language pack, so technically it is possible. >>>> >>>> Jan. >>>> >>>> On 23 November 2012 15:47, Rob Weir <robw...@apache.org> wrote: >>>> >>>>> On Fri, Nov 23, 2012 at 9:30 AM, jan iversen <j...@apache.org> wrote: >>>>>> If it is easier, we could keep the binary, and just release language >>>>>> packs....a bit more uncomfortable but still an official release ! >>>>>> >>>>> >>>>> I'm just thinking ahead, to the very real possibility that we're >>>>> adding new languages on a continual basis until we're shipping 100+ of >>>>> them. If that happens we're going to create absolute chaos if we >>>>> encoding version changes in a way that appears externally to scripts, >>>>> extensions, in documents, to upgrade servers, etc. It will lead to a >>>>> proliferation of version strings that will destroy us all. This is >>>>> what the Mayans were warning us about !!! >>>>> >>>>> (OK, maybe not that bad, but it would be quite a mess) >>>>> >>>>> But if we can consider these new languages to be merely the >>>>> continuation of the 3.4.1 release, and an keep the external behavior >>>>> of the program the same, then live is easy. We can release full >>>>> versions of Danish, etc., 3.4.1. All we need to do is vote on a new >>>>> source tarball which could be called AOO341-danish-patch.tgz or >>>>> whatever. >>>>> >>>>> -Rob >>>>> >>>>> >>>>>> Jan. >>>>>> >>>>>> On 23 November 2012 15:01, Rob Weir <robw...@apache.org> wrote: >>>>>> >>>>>>> On Fri, Nov 23, 2012 at 3:39 AM, Jürgen Schmidt < >>> jogischm...@gmail.com> >>>>>>> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> we all know that the number of volunteers helping with >>> translation is >>>>>>>> growing and we would like to make new languages as soon as >>> possible >>>>>>>> available. This is important for two reason, first to make AOO >>>>> available >>>>>>>> in further languages to reach more users. Second to show our >>>>> volunteers >>>>>>>> that their work is appreciated and become integrated as soon as >>>>>>>> possible. We don't have a well defined process for doing it at >>> moment >>>>>>>> but we will find a working way that will be ok for all of us. And >>> we >>>>> can >>>>>>>> improve it over time when see demand for changes or improvements, >>>>> means >>>>>>>> we don't have to find a 100% perfect solution from the beginning. >>>>>>>> >>>>>>>> The most important part is how we do the naming of the different >>> parts >>>>>>>> of such a release. >>>>>>>> >>>>>>>> I see two different scenarios: >>>>>>>> >>>>>>>> 1. Only new languages, no bugfixes, no other code changes >>>>>>>> We add the new languages on top of the existing AOO34 branch, >>> build >>>>> the >>>>>>>> office with the new languages and release the new languages as >>>>>>>> convenience binary packages. We also build a new src release >>> package >>>>> and >>>>>>>> add the revision number in the name to identify a respin of the >>>>> orginal >>>>>>>> 3.4.1. >>>>>>>> >>>>>>>> For example: aoo-3.4.1-rev1372282-src.tar.bz2 >>>>>>>> >>>>>>>> This new src release becomes the default for 3.4.1 because it is a >>>>>>>> respin only (no functional changes) >>>>>>>> >>>>>>>> The revision number is part of the about dialog as well and it is >>>>>>>> possible to identify the respin. >>>>>>>> >>>>>>> >>>>>>> If we change the about dialog does this change anything else? For >>>>>>> example, does it change what is written into ODF documents for the >>>>>>> creator string? Does it cause AOO to report a different version to >>>>>>> scripts? If we change anything more than the UI strings we risk >>>>>>> breaking 3rd party scripts who have logic tied to 3.4.0 or 3.4.1. >>>>>>> >>>>>>> -Rob >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 2. New languages + bug-fixes or security fixes >>>>>>>> The micro number will be increased and we do a normal release >>> cycle. >>>>>>>> The src release will contain the revision number in future always. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Concrete proposal for 3.4.1 and new languages: >>>>>>>> >>>>>>>> 1. set a deadline for new translations, for exmaple December 31, >>> 2012 >>>>>>>> 2. integrate the new languages and provide the builds until >>> January >>>>> 10, >>>>>>> 2013 >>>>>>>> 3. test and verify the new language builds asap >>>>>>>> 4. release the new languages at the end of January >>>>>>>> >>>>>>>> >>>>>>>> Why a deadline until December: >>>>>>>> The reason is quite simply, we have 22 languages with an UI >>> coverage >>>>> of >>>>>>>> more than 95% (ok Turkish 93%). My plan is to prepare a blog >>> entry and >>>>>>>> call again for volunteers for these languages where the effort is >>>>>>>> moderate. My hope is that we can integrate a few of the important >>>>> ones. >>>>>>>> >>>>>>>> UI coverage with more than 93% >>>>>>>> ============================== >>>>>>>> 100%: Danish >>>>>>>> 98%: Korean, Polish, Asturian, Uighur, Icelandic, Indonesian, >>> Welsh, >>>>>>>> Catalan, Bulgarian, Latvian >>>>>>>> 97%: Greek, Basque >>>>>>>> 96%: English (South Africa) >>>>>>>> 95%: Portuguese, Swedish, Marathi, Kannada, Gujarati, Irish, Oriya >>>>>>>> 93%: Turkish >>>>>>>> >>>>>>>> >>>>>>>> Juergen >>>>>>> >>>>> >>> >>> Less well informed users (i.e., the majority of ordinary, >>> computer-unskilled users) expect to get a complete package for their >>> language, with no extra downloading or customisation required. Might it be >>> possible to package the language packs in such a way that the "complete >>> pack" consisted of the basic unit (en-US) and the specific Language add-on, >>> and an "invisible" script automatically installed the Language add-on, >>> thereby giving the same effect as a compiled national language version? >>> >>> -- >>> Rory O'Farrell <ofarr...@iol.ie> >>> > >
