Hi Kai,
we ( Pavel , Ause , me ) had already some ideas how to remove the
localize.sdf files out of the source tree. We want to create a new
"translation" module containing all the stuff.
/translation
/translation/be-BY
/translation/be-BY/localisation.sdf
/translation/bg
/translation/bg/localisation.sdf
..
Each language subdir contains one file with the translations for the
whole source. The file could contain the localisation only or for status
tracking additional the correspondig en-US strings. A build && deliver
within this module triggers a modified localize.pl script that spread
the files into the solver tree like:
localize --solver -m -l be-BY -f /translation/be-BY/localisation.sdf
localize --solver -m -l bg /translation/bg/localisation.sdf
or
localize --solver -m -l all /translation/*/localisation.sdf
-> merge localisations found in translation module into the solver
unxlngi6.pro/misc/translations/automation/source/miniapp/localize.sdf
unxlngi6.pro/misc/translations/avmedia/source/framework/localize.sdf
unxlngi6.pro/misc/translations/avmedia/source/viewer/localize.sdf
...
Resources will be build only if the WITH_LANG variable is set. If so the
l10n tools are called using the translations from the solver. There
are some (dis-)advantages with this solution
Pros:
-Checkout faster as the translation module is not part of the
OpenOffice2 alias
-Translations are easy to update / change by replacing the corresponding
sdf file in the translation module
-It is possible to easy cvs diff between milestones/cws/masterworkspace tags
-Localisations are independend / degenerated from the source code tree
Cons:
-Dublication of the translations ( ~ 1 GB )
-In times of unstable cvs services it can be painfull to handle huge and
clumbsy files. The upper limit that should not exceed is the the most
evil localize.sdf found in helpcontent2 is :
53MByte text/scalc/01/localize.sdf
This file is growing and growing, while the amount of strings each
milestone in the translation module should not grow that fast. A current
big size Khmer l10n file for example is
18 MByte km + 12 MByte en-US
Can we keep this in sync with your UnHack activities?
Cheers,
Ivo
Kai Backman wrote:
It's also possible to split out the l10n files like localize.sdf and
still build using them. In the UnHack SVN repos we have separate trunk
(source) and data-trunk (l10n, other data). We use configure to share
a data-trunk checkout (or just download) between several source
trunks. Usually data-trunk being out of date does not create huge
problems for day to day development. Obviously packagers want the full
up to date version.
Aside from reducing download size significantly this also reduces
working copy size. A cvs co OpenOffice2 is 1.5GB (!!) on local disk.
The core source itself is just 300-400 MB of this.
On 11/1/06, Stefan Taxhet <[EMAIL PROTECTED]> wrote:
Hi,
Joost is on vacation but will return later this week.
Gretings
Stefan
Jan Holesovsky wrote:
> Hi Joost,
>
> Did you have time to have a look, please? ;-)
>
> It would be really great to have common source packages up-stream & for
> ooo-build...
>
> Regards,
> Jan
>
> On Wednesday 02 August 2006 09:54, Jan Holesovsky wrote:
>> Hi Joost,
>>
>> Please - did you have time to have a look? If you have any
>> comments/requests for improvements of the script(s), I can do it -
just
>> tell ;-)
>>
>> Thank you, and regards,
>> Jan
>>
>> On Tuesday 18 July 2006 18:36, Jan Holesovsky wrote:
>>> Hi Joost,
>>>
>>> On Tuesday 18 July 2006 17:51, Joost Andrae wrote:
>>>>> Be aware that the current script operates destructively :-)
>>>> it splits ? ;)
>>> Not just splits - it deletes the already packed parts; can be
fixed for
>>> you of course ;-)
>>>
>>>>> So - the rational for splitting the source is simple: download
times
>>>>> are important, they're important for me, and I'm on a fast link ;-)
>>>>> by splitting out binfilter, l10n, common system bits etc. we get a
>>>>> 110Mb source archive that is a far smaller download [ and still
>>>>> includes all the CVS/ data for easy hacking ].
>>>> Your points are valid. I need to check the effort on my side.
>>> You can find the scripts attached; the most interesting for you is
the
>>> one named 'src-pack'.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
