All patches have now been attached in dependent bugs.
This should include all the steps to build localized
(http://l10n.openoffice.org/adding_language.html) as well as following all the
changes from the Slovenian bug (tracking bug 20086)
Using the following codes:
 Afrikaans - af - 28
 Northern Sotho - ns - 26
 Zulu - zu - 28
Note that ns should be nso but three letter characters are not currently supported.
Also, the codes 26 and 28 are temporary codes until the dialing code system is
dispensed of

Afrikaans is 27.

Created attachment 14608 [details]
Patch for South African support (relative to OOo 1.1.1)

Created attachment 14609 [details]
Afrikaans GSI 1.1.1 (encodings fixed)

Created attachment 14610 [details]
Northern Sotho GSI 1.1.1

Created attachment 14611 [details]
Zulu GSI 1.1.1

Have added latest patch and GSI files.
These are still based on 1.1.1 but should not be too different for 1.1.2 ...
Targetting for inclusion in 1.1.2

Thanks, David.

.

gh: Please merge into 1.1.2

> Note that ns should be nso but three letter characters are not currently
supported.

Note that use of the "ns" fake code will result in

1. documents that can not be read (in terms of assigning the proper locale
attribution) by an upcoming OOo2.0 as OOo2.0 will use the proper "nso" ISO code
instead. This can be circumvented by having a second mapping for the "ns" fake
code, unless item #3 would be effective.

2. OOo1.1.x not being able to assign locale attribution of documents created
with OOo2.0 as OOo2.0 will always write "nso" instead.

3. confusion if ISO639 came up with an assignment for "ns".

4. maybe language pack mechanisms of distributions like Debian and Mandrake not
working, as the environment setting "nso" will not match the fake "ns".

To overcome this situation I can only suggest to change at least the
tools/source/intntl/isolang.cxx IsoLangEntry.maLangStr to a length of 4 to be
able to hold three character codes, and use the proper "nso" mapping in the
aImplIsoLangEntries table. Note however that this is untested so far. It doesn't
do any harm to already existing 2 character code locales, but is not guaranteed
to work with 3 character code locales in all aspects, but it might work.

Eike

Patch merged in cws_srx645_ooo112fix1.

linux sparc and mac osx

reading file /var/tmp/temp040216fca7 .
reading file /var/tmp/temp04021bb99b ......
reading file /var/tmp/temp04021a870e ..
reading file /var/tmp/temp04021eb48f .
< "U?ivatelem definovaný 9" ; LANGUAGE_USER9 ; > ;
                                              ^
f640: "langtab.src", line 4037: Error: parse error

f256: Error: !! 1 Error found!!
Error starting rsc2 compiler
dmake:  Error code 1, while making '../../unxmacxp.pro/srs/dialogs.srs'
---* TG_SLO.MK *---
dmake:  Error code 255, while making 'SRC1'
---* TG_SLO.MK *---

ERROR: Error 65280 occurred while making /ooo112b/svx/source/dialog
dmake:  Error code 1, while making 'build_all'
---* TG_SLO.MK *---
[powermacg4:/ooo112b] christianzwahlen%

I will attach this patch to allow the building to proceed but needs to be
reviwed please.

Created attachment 14700 [details]
langtab patch

committed that langtab.diff in cws_srx645_ooo112fix1

Replacing LANGUAGE_USER9 with EXTERN is correct, that's the famous 99 ...
The scrambled mess in that file is the long known problem with merges from the
translation database, when localizations aren't fully translated yet. Nils,
Ause, and Ivo might tune into a nasty song about that ;-) just mention "merging
StringArray ItemLists" ...

The scrambling doesn't do any harm as long as no localization that was already
finished on that branch is affected. Otherwise the result would be that
selecting a language from a listbox would trigger using a different language
instead. The same problem holds true for the text encoding listbox's content of
txenctab.src and other .src files using StringArray ItemList.

  Eike

It's wierd for LANGUAGE_USER9 to produce an error as its in tools/inc/lang.hxx
... and it seems wrong to define this as EXTERN, but it seems most languages
have the last few entries a bit confused and no-one else has LANGUAGE_USER9.
Should this be fixed more generally?

The language identifiers used in resource files aren't directly those of
tools/inc/lang.hxx though derived from it. In fact only LANGUAGE_USER[1-8] have
identical names, all others have the LANGUAGE_ part stripped. The language
identifiers known to the resource compiler are those of rsc/inc/rsclang.c and
rsc/source/parser/rscibas.cxx, of which the latter implements a method
RscTypCont::InitLangType() where the LANGUAGE_USER[1-8] and EXTERN are defined.
EXTERN previously was LANGUAGE_USER9 but was changed with the introduction of
the l10n framework that uses the EXTERN 99 mechanism, probably to distinguish it
from the other LANGUAGE_USER values. Not sure about that one, or if there were
also other reasons, Hamburg release engineers might know.

As OOo2.0 (hopefully) will introduce use of ISO names as language tags in
resource files, situation will change completely.

Btw, this issue is assigned to 'gh' (Gregor) but Pavel stated that he already
committed the sources to ooo112fix1. I think one of you guys should set the
status to resolved fixed ;-)

er: this is now about merging GSI files ('two in one' issue ;-)

merged the sdf files in CWS mergepp3

verifying

Back to You

set status to fixed

close issue