SOURCES: monodoc.desktop (NEW) - desktop file

Tomasz Pala gotar w polanet.pl
Sob, 28 Lut 2004, 16:07:10 CET


On Sat, Feb 28, 2004 at 15:13:01 +0100, Paweł Sakowski wrote:

> Jedna sprawa to wybór spośród różnych wariantów np. Name[xxx] właściwego
> dla danego locale. Tu sprawę rozwiązuje tabelka 1. standardu -- czyli
> dla locale (a dokładniej mówiąc, LC_MESSAGES) pl_PL brane są pod uwagę
> Name[pl_PL], Name[pl] i Name (z dokładnością do sufiksu .ENCODING).

No i tak właśnie vfmg robi. Z tym, że przed LC_MESSAGES bierze LC_ALL, a
po nim LANG. Nie wiem czy do końca zgodnie ze standardem, czy nie -
dokładną obsługę zmiennych systemowych zrobię na końcu.

> Druga sprawa to sposób przedstawienie tej informacji. Tu trzeba, w
> ogólnym przypadku, przekodować stringa. Kodowanie wyjścia określa
> $(locale charmap), niezależnie od konkretnego pliku desktop. W przypadku

I żeby nie robić tego ręcznie, używam "use open OUT => ':locale'", a
wewnętrzne struktury danych trzymam w UTF-ie.

> pl_PL może to być ISO-8859-2, ale nie musi. Kodowanie wejścia to albo
> UTF-8 albo, w przypadku Legacy-Mixed, określone jest przez załącznik D
> standardu. I dla przykładu: jeżeli locale jest pl_PL a w pliku .desktop
> występuje jedynie linia Name[pl]=xxx, to linia ta jest interpretowana
> jako ISO 8859-2, niezależnie od ustawień locale konkretnego systemu. Tak
                                                  ^^^^^^^^^^^^^^^^^^^
> samo byłaby potraktowana linia Name[pl_PL]=xxx.

Ale żeby uzyskać to 'ISO-8859-2' muszę użyć Langinfo (bo innej metody
nie znam - jeśli ktoś zna funkcję get_encoding(język) to niech mi jak
najszybciej ją poda). A to operuje na aktualnym locale. Zatem vfmg
przestawia locale na zawartość [...], wywołuję tę funkcję i przywraca
stare locale. Krótko mówiąc ustawienia locale systemu mnie tu w ogóle
nie interesują. Problem pojawia się wtedy, gdy zamiast [pl_PL.ISO...]
czy [pl_PL] pojawia się samo [pl], bo takie locale NIE istnieje. I to
jest jedyna znana mi odchyłka od standardu w zakresie znaków. A jeśli
masz na myśli coś innego, niż poleganie na localach systemowych (gdyż
jak napisałem nie ma to miejsca w strumieniu WEjściowym a jedynie tym
WYjściowym), to weź aktualne vfmg z CVS-u, znajdź blok rozpoczynający
się ciągiem 'Legacy-Mixed', przeanalizuj go i podaj proof of concept,
bo nie rozumiem już, o jakim przypadku mówisz. Odnoszę wręcz wrażenie,
że dzięki separacji wejścia i wyjścia (tj. dowolny encoding WE->UTF, a
później UTF->wybrany localami lub opcjami encoding WY), uniezależniam
się od tego, o czym mówisz, gdyż miałoby to miejsce właśnie wtedy, gdy
wartość klucza [xx] bym _przepisywał_ dla systemu z localami xx, zatem
to wtedy by nie były uwzględnione różne kodowania dla jednego języka.

Innymi słowy: skąd uzyskać informację, że [pl] oznacza ISO-8859-2?

-- 
GoTaR <priv0.onet.pl->gotar>
http://vfmg.sourceforge.net/



Więcej informacji o liście dyskusyjnej pld-devel-pl