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>
