Hello,
El dc 25 de 10 del 2006 a les 20:46 +0200, en/na Eike Rathke va
escriure:
> > My progress to produce a Valencian-Catalan locale support patch is
> > mostly blocked by the lack of a Microsoft Locale ID for this.
> No, unfortunately that's not the main blocking thing. As already
> mentioned 3 weeks ago, Valencian-Catalan is no separate language and
> doesn't have an ISO 639 code assigned, and modifiers respectively
> variants or subtags aren't supported yet by OOo, nor could
> a corresponding language tag be stored in the OpenDocument file format
> (ODF). Currently it is nearly technically impossible to support the
> construct of a dialect as a separate language.
I've re-read your previous message, and I realise I didn't understand
what you meant with:
| | My concern is that can be used as a some kind of non-scientific
| | justification for some ultra right wing Spanish nationalists who
| | claim that "Valencian" and "Catalan" are two different language
|
| Unimportant, as long as neither ISO nor IANA have a language code
| assigned, it's no distinct language for all standards compliant
| applications.
I thought you were talking about the "language war", not about
supporting the Catalan-related variant in OpenOffice.org.
I see I'm alone in the desert right now. I'll have to do an internal
build for a weird "valencia_ES" locale though, so I can still use some
advice from the list.
> > When and how do internal locale codes get assigned once you've mailed
> > this list?
> Usually it's up to me to assign LangID codes. However, in this case it
> is pretty much pointless to do so, as there is no valid mapping to the
> ISO and file format constructs used by OOo. This has to be solved first.
Right. I guess there's nothing we can do right now, while there's no
variant/script/subtag support. Or is there some other way we can go to
accomplish this? The locale we're using for gettext is "[EMAIL PROTECTED]",
as this is supported and works perfectly for that i18n system. We wanted
to use something that could map to that in OOo.
> > For example, in
> > i18npool/source/isolang/isolang.cxx, MsLangId::IsoLangEntry, I added
> >
> > // { LANGUAGE_CATALAN_VALENCIAN, "ca", "ES" }, // Modifier
> > names not supported yet ([EMAIL PROTECTED])
>
> This would introduce ambiguousness to an already existing mapping:
>
> { LANGUAGE_CATALAN, "ca", "ES" }, // Spain (default)
>
> and is not "round-trip-safe", conversions back and forth between that
> mapping would not produce identical identifiers, which is essential for
> using it in attribution and storage.
Yeah, that's why I commented it. Technically, if a document edited with
a hypothetical Valencian OOo, I wouldn't mind if the document had the
same language tag as the purely Catalan version. The only interesting
changes are UI wise: dictionaries, output files and such could be
exactly the same.
> > and for IsoLangNoneStdEntry,
> > { LANGUAGE_CATALAN_VALENCIAN, "ca", "valencia" }, //
> > [EMAIL PROTECTED] locale
>
> This would not produce a valid language/country pair as currently
> required by ODF. See also section "15.4.23 Language" and "15.4.24
> Country" of
> http://www.oasis-open.org/committees/download.php/12573/OpenDocument-v1.0-os.sxw
> that refer sections "7.9.2 language" and "7.9.1 country" of the XSL
> http://www.w3.org/TR/2001/REC-xsl-20011015/ specification, which in turn
> refer RFC 3066 http://tools.ietf.org/html/rfc3066
I see. I tried mimicing the Serbian Latn/Cyrl examples in the file.
> A possible solution according to RFC 3066 could be an identifier
> "x-valenc" as language and "ES" as country, would had to be verified
> though whether that is really usable within OOo. However, that would be
> a private extensions and would not be recognized by any other
> application, not even as being related to Catalan, which I consider
> a major drawback and therefor hesitate to use the IsoLangNoneStdEntry
> mechanism. I would only use it as a very last resort.
The Valencian government produces an educational GNU/Linux distribution,
LliureX, which for the usual political reasons did not use a standard
locale like the proposed "[EMAIL PROTECTED]". Instead, it went the non-ISO
639 route of inventing a "valencia_ES" locale, which doesn't stomp on
the ISO 639-2 namespace, and is still usable by Gettext.
When I did the Valencian version of OpenOffice.org 1.1.3, I ran into
problems with such a long locale "valencia_ES". In the end, IIRC, I
ended up using "va" internally, and somehow, can't remember now, I
mapped it to valencia_ES.
> Are you sure you want to go that road with all implications it might
> have?
For our internal LliureX build, I can go with an non-standard identifier
like the one you propose, but my idea is that I would just patch it from
the correct [EMAIL PROTECTED] based support.
If there's absolutely no way I can integrate such locale in
OpenOffice.org proper, then it won't be possible to ever have a public
Valencian build for Softcatalà (Jesús' and my translation organisation),
which sucks. If there is a way, I'm interested in knowing what it'd
imply.
If it didn't work out, is it possible to reserve an unofficial LangID
for us even if it's never used officially? That way, I could work on
custom patched builds using "my" langid knowing I'll never stomp on
anyone's feet in the case a new locale appears/gets assigned.
> > Is this going to work at all?
>
> Not yet. Vaiants would need modifications to the file format and several
> modifications to the source code, probably throughout the entire
> application suite.
Yes, Ivo told me about a year ago, and warned me that this would
probably wouldn't happen in some time. Can you estimate how much?
> Sorry I can't tell you "hey, that's easy, just do this and that" ...
I hope I've explained the situation a bit better now. No matter what,
I'll have to do a custom, hackish if needed, build for LliureX, using
whatever locale I need to use. The idea was to have compliant support in
the official repository though, so that a "good" Valencian version can
be produced.
Thanks,
--
Jordi Mallach Pérez
Conselleria de Cultura, Educació i Esport
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
