[ooo-build-commit] .: 2 commits - autogen.sh doc/l10n.txt doc/layout.txt
Michael Meeks
mmeeks at kemper.freedesktop.org
Mon Oct 4 01:49:11 PDT 2010
autogen.sh | 2 -
doc/l10n.txt | 110 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
doc/layout.txt | 1
3 files changed, 111 insertions(+), 2 deletions(-)
New commits:
commit a0dce34d7c08cf82d7284bd29c92324c973e7da7
Author: Michael Meeks <michael.meeks at novell.com>
Date: Mon Oct 4 09:47:53 2010 +0100
don't give bogus portability warnings
diff --git a/autogen.sh b/autogen.sh
index 0805e70..f0cc1d0 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -27,7 +27,7 @@ fi
touch ChangeLog
aclocal $ACLOCAL_FLAGS || exit 1;
-automake --gnu --add-missing --copy || exit 1;
+automake --gnu --add-missing --copy --warnings=no-portability || exit 1;
# intltoolize --copy --force --automake
autoconf || exit 1;
if test "x$NOCONFIGURE" = "x"; then
commit e1956e2b5737c5dc556d376ff626ddda963b6432
Author: Michael Meeks <michael.meeks at novell.com>
Date: Mon Oct 4 09:13:32 2010 +0100
thoughts on l10n
diff --git a/doc/l10n.txt b/doc/l10n.txt
new file mode 100644
index 0000000..b44c11e
--- /dev/null
+++ b/doc/l10n.txt
@@ -0,0 +1,110 @@
+* 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 ?
+
+
+
+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.
diff --git a/doc/layout.txt b/doc/layout.txt
index 25cacba..cff50e8 100644
--- a/doc/layout.txt
+++ b/doc/layout.txt
@@ -2,7 +2,6 @@
[ Search for '----' for the live stuff at the bottom ]
-
Some thoughts on coding up layout.
* Resource compiler (rsc/source/*)
More information about the ooo-build-commit
mailing list