Languages in my build system
My build system is used by people who can't build their languages on
some systems. It is time consuming to provide builds for many
languages on more systems, thus I have to set some rules. They are
very simple - I only build for active languages.
When there is an issue with the language, I expect some response. When
the GSI file contains bugs, I expect them to be fixed soon without me
doing anything - the output of the build system provides enough
informations for everyone to fix their GSI files (more on this
below). I also expect regular updates to the GSI files. It doesn't
make sense to build your language when you update your GSI file just
once before the release. I can use the resources for other
languages. It also doesn't make sense to build languages that are not
based on newer POT files.
This document is a small HOWTO that should help you to make
integration smoother. I'll only integrate languages with
active
teams and I'll remove languages of in-active teams. I do not want to
build the language that has old, unmaintained GSI files, because the
CPU time, disk space and bandwidth can be used for other active
languages instead.
So what you should do to have your language added?
- mail me the ISO code of your language and technical contact for
your language
- Please make sure that the data about your language in our table are correct and complete.
- Please send me the URL of your GSI file that is named GSI_cs.sdf.bz2 (bzip2 or gzip compressed
GSI file where cs is the ISO code of your language). If you'd like to know the reason for this,
see the script
updating all GSI files I run just before every build.
- regularly check the outputs of the build system - both
installsets and also bug output files ;-)
I expect that the submitter of GSI file handles issues in their GSI
file. Mistakes happen, but what should not happen are mistakes that
are not fixed ;-) I do upload several files you can use to check/fix
your GSI files. They are stored in the
directory
http://ftp.linux.cz/pub/localization/OpenOffice.org/devel/680/SRC680_m222/Build-1/build/
(this applies to SRC680_m222 which is the latest, right now).
One type of such files are .err files. This is the output from
gsicheck utility which you should always use before uploading your GSI
files. If the .err file for your language exists, you have a problem!
You should fix it.
Another type is .warnings file. This file contains error output from
the tool that is merging the translations back to the sources. It
reports problems when e.g. the file it should merge into doesn't exist
in the sources. This means that you have used incorrect/old POT files
to create your GSI file! You should fix it.
I'll update this blog entry with comments from active languages. The
next blog entry will summarize the status of GSI files in my
SRC680_m222 builds.