[Open Office] Localization docs update & new idea

[Petr Mladek]

On Thursday 21 September 2006 20:12, Robert Vojta wrote:
> Hallo Peter,
>
> I just followed your advices about GSI files and it works perfectly.
> But I found one case where it doesn't work. Let's assume you have
> distro-configs/ABC and you know, that you'll always build with
> three languages only (en-US, cs, sk). So, you put these languages
> in distro-configs/ABC and you start ./autogen.sh --with-distro=ABC
> (without --with-lang, because they are in distro-configs/ABC). And now,
> the GSI localization part doesn't work, because $OOO_LANGS_LIST
> variable contains "en-US" only. Do you think it is worth to fix this,
> invest time?

I see. It is doable. You would need to replace all occurences of 
OOO_LANGS_LIST with the variable WITH_LANG, which is defined in the OOo 
native profile (LinuxIntelEnv.Set.sh).

The variable OOO_LANGS_LIST is used in setup.in, build-ooo, ooinstall, and 
package-ooo. You can remove it from setup.in because it won't longer be used. 
The variable WITH_LANG will be available in the other locations, because the 
native profile is sourced there.

The only problem is the you would need to transform "ALL" to the real list of 
languages. I vote to do it in the config_office/*. Probably, the best place 
would be config_office/set_soenv.in. I think that you can use the same hack 
that is used in setup.in to generate OOO_LANGS_LIST.

In fact, I would prefere to remove solenv/inc/postset.mk and put the list of 
all languages into config_office/set_soenv.in. Though, it has to be dicussed 
with Sun people. They do not use the config_office module at all, so...

Note: We would like to merge ooo-build features into the upstream framework. 
My idea is to merge the configure options and variables, add our extra 
scripts into the config_office module. So, I think that the proposed solution 
is a step forward, definitely.

> Next thing is, that I updated doc/extra-localizations.txt file.
> Your advices are included.

Looks nice!

> And now, an idea how to translate new ooo-build features. I was
> thinking about this issue for a while. This idea came to my mind.
>
> 1) For translators
>
> There should be string freeze before new release of ooo-builds.
> After the string freeze, POT file will be regenerated.
>
> Translators can grab them, translate PO files (based on POT file)
> and give them back.
>
> POT file will be generated from all patches, scratches.
>
> This is easy way for translators and easy way for ooo-build
> maintainers.

Sounds great. The only problem is how to extrac/merge the po files from/to 
patches/sources.

I see two ways:

1. Create "simple" scripts that would work directly with patches
	+ advantages
		+ fast
	+ disadvantages
		+ I am a bit scared by syntax analyzer (diff of a source)

2. Use the existing localize tool:
	+ advantages
		+ probably more save way
		+ easier to maintain
	+ disadvantages
		+ you need to build the localize tool
		+ it takes a while to extract/merge many localizations
		+ the gsi file is quite a big

Well, I prefere the second solution:
	+ we will extract the strings only few times a year, so it does not matter if
          it is slow.
	+ We could create extra GSI files only with the ooo-build specific strings.
          It will be very small, quickly applied, ... It would be a bit tricky
          to locate the ooo-build specific strings. Though, it should not be
          so hard and we should do it anyway.

> 2) Auto merging during build
>
> Today's GSI file handling functions should be enhanced in this
> way.
>
>   o enhance stamp/build.extra.translations - add timestamp of GSI
>     files and PO files
>
>   o check for new GSI / PO files, their timestamps, and translate
>     ooo-build build tree when new / updated file arrives

This is exactly what I thought about.

> Any comments? Enhancements? It's just an idea which should be
> finished. Do you agree with this? If yes, I'll implement this
> idea into ooo-build.

Sounds great. I am a volunteer for reviewing/testing your changes if you need 
it.


Best Regards,
Petr