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, > > 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> > > -- Rory O'Farrell <ofarr...@iol.ie>
