* notes on new l10n packaging

.res files could be shrunk by splitting strings out
	+ 540795  - gzipped with strings
	+ 214380  - just the strings
		=> we have a 50% size win for translation possible
		=> we could profitably split strings out into
		   separate files by hacking the resource compiler.
		=> cf. layout.txt for rsc etc. code details

* but *
	+ the biggest waste of space is templates ...
	* split the help [ as on Linux ]
		+ sort out templates [!] ...

	* so [!] - investigate template translation ...
		+ where do they come from ?
			+ extras/source/templates/wizard/report/lang/... etc.
			+
		+ how are they translated ?
		+ why is it -so- lame ? :-)
			+ can we do it in some better way ?
			+ with XML diffs or something ?

	* File->Wizard
		+ -already- manipulates the documents ...

	* http://www.openoffice.org/issues/show_bug.cgi?id=99480
		+ default font usage in impress.


The conclusion / design:

                So in my view this problem really exists only for Windows (and
        perhaps Mac), Linux users are sophisticated, get their OO.o from their
        distribution (mostly), and can cope with the concept of multiple
        packages being required. So - what about Windows:

        On Fri, 2010-09-17 at 08:44 +0200, Sophie wrote:
        > So to be more precise on our needs if we build full versions for day one :
        > Currently we have 41 one full builds and 68 lang packs for 8 plateforms
        > for 3.2.1.
        ...
        > For 3.3 beta we have about 100 registered languages and 8 supported
        > platforms. A full build is approx. 170 MB where a langpack is 21 MB
        > approx. Who will grant us enough space, power, etc to get the full
        > builds available for download next week?

        So - if we do a taxonomy of lang-packs, what do we find (based on russian).

                Component                    Compressed size (Kb)
                ---------                    ---- ru ---- fr ----
                user interface strings           610     590
                dicts, hyphenation, thesaurus    750    1600
                translated templates            1500    1400
                help documentation             11000   11000

                My ideal would be to ensure that when you download OO.o you
        get translations for every language; and I think we can achieve that.

                To do it - we have to do three things, which I recommend:

                a) create help-packs - split out the help for each language
                   and simply have no help installed[1], but a web link to on-line
                   help[2], and a "download your help-pack here" direction
                        + not even English help would be installed -
                          this will save us 11Mb in the 170Mb download

                b) fix template translation: this is -incredibly- wasteful,
                   there is lots of duplication of images, compressed XML
                   document content etc. etc.
                        + almost none of that is really useful.
                        + we need a good way to internationalise documents /
                          templates anyway

                c) ship -all- language translations with dicts and hyphenation
                   for the core 41 languages in the download: this would be
                   (say) 2Mb each (depending on dict, hyphenation, thesaurus)

                If we add up the sizes of these in Mb we get:

                        170 (original size incl. English)
                        -11 less English help, strings etc.
                        +80 (40 * 2Mb)

                Which is 230Mb. That adds an extra ~40% to the download, -but-
        simplifies a lot of things. It should allow anyone to get up to speed
        quickly in the vast majority of the world's languages. It would also
        cut our mirror site's hosting requirements by some large factor, allow
        us faster builds, not discriminate against any language [ except the
        other separate lang-pack langs we have already ], and be "a good
        thing" (TM).

                Personally I don't think we need to be -that- worried about
        overall download size of this kind anyway.

                Is my solution work-able ? did I miss some requirement ?

                Technically we would need to do some work here; particularly
        b) requires some active development effort.

                If we can choose where to spend our effort - I would strongly
        prefer this general solution that should make things easier for almost
        everyone [ except frequent installers, that use help heavily ].

                HTH,

                        Michael.


        [1] - the studies on help's overall usefulness are not that
              encouraging anyway cf.
                http://people.gnome.org/~michael/blog/2007-02-06.html
        [2] - on-line help may give us useful page-hit traffic data on
              what people are really struggling with anyway.
