www-pl-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [www-pl-discuss] NBSP; czyli niełamliwe spacje.


From: Sylwester Zarębski
Subject: Re: [www-pl-discuss] NBSP; czyli niełamliwe spacje.
Date: Mon, 30 Aug 2010 00:02:23 +0200

29 sierpnia 2010, 20:14:38, Paweł napisał(a):

> On 29.08.2010 15:24, Sylwester Zarębski wrote:
>> 29 sierpnia 2010, 13:51:30, Paweł napisał(a):
>>>    Sprawdzanie na gotowych plikach jest niewygodne. Po pierwsze długi
>>> cykl, po drugie dwa programy przy poprawianiu (przeglądarka i edytor
>>> plików po).

Z poniższej dyskusji wynika, iż wprowadzenie konwersji spowoduje
konieczność dodatkowo korzystania z odpowiedniego konwertera, więc
będzie trzeba używać trzech programów: edytor gettext, konwerter, a
następnie przeglądarka. Nie widzę w tym zysku.

>>>    Ale przyszedł mi do głowy inny pomysł - stosowanie w plikach pl.po
>>> zamiast  dwóch spacji (o zastosowaniu podwójnej spacji już
>>> rozmawialiśmy i nie chcieliśmy go w oryginalnej postaci). Co to daje?
>>> 1. Będzie zachowana normalna czytelność.
>>> 2. Będzie zachowana możliwość automatycznego sprawdzania pisowni.
>>> 3. Będzie możliwość prostego wstawienia  - wystarczy zamienić ciąg
>>> dwóch spacji na  przed konwersją do HTML - trywialne do wykonania
>>> automatem.

>>> Wada jest taka, że trzeba konsekwentnie używać dwóch następujących po
>>> sobie spacji (nie wycinać ich, nie stosować wersji z oryginału), a
>>> spacje nie w każdym edytorze są dobrze widoczne. Co sądzicie?

>> Wg mnie to zły pomysł ze względów stricte technicznych:
>> 1. Dwie spacje łatwo wstawić nieumyślnie.

>   Zależy od edytora, ale tak. Przy czym nic nie wybuchnie w przypadku 
> błędnego wstawienia dwóch spacji - podzieli wyraz wcześniej/później i tyle.

Owszem, tylko, że to kłopot jeśli te spacje spowodują brak podziału
dopiero gdzieś na etapie końcowym. Nic się co prawda nie stanie, ale
sens stosowania zostanie nieco wypaczony.

>> 2. Trzeba pamiętać, że w CVS powinna być dostępna wersja finalna,
>> którą można łatwo sprawdzić i poprawić.

>   I dokładnie taka będzie. Łatwa do sprawdzenia (w tym automatycznym 
> słownikiem), łatwa do poprawy. Więcej, wygenerowanie ostatecznego HTML z
> niej, bez zamiany podwójnych spacji na   także nie będzie wielkim
> błędem.

Wersja finalna to wersja HTML, czyli taka jak wędruje do repozytorium
głównego GNU. Wersje w naszym CVS i w CVS głównym powinny być moim
zdaniem identyczne. Finalne, czyli w HTML. Czyli tak jak obecnie.

>> 2a. Jeśli konwersję miałby dopiero robić committer (czyli wódz grupy),
>> to otrzymuje na głowę wszelkie problemy techniczne z powodu różnic
>> pomiędzy plikami źródłowymi i wynikowymi, jak również przed oficjalną
>> publikacją następuje problem weryfikacji wizualnej tłumaczenia.

>   Problem weryfikacji wizualnej ma i teraz (o ile w ogóle sprawdza 
> wygląd wynikowy - pytanie czy sprawdzanie w ogóle ma sens, bo rozmiarów
> ekranu, ustawień, wielkości czcionek itd. jest masa, na pewno gdzieś 
> wyjdzie lepiej, a gdzieś gorzej).

Jeśli weźmiemy pod uwagę, że HTML nie ma za zadanie odwzorować wyglądu
per pixel, ale prezentować treść, to nie ma problemu. Tekst się złamie
tam gdzie trzeba zgodnie z zasadami języka.

Tak sobie również pomyślałem, że jeśli chodzi o sprawdzanie pisowni,
to zapewne większość edytorów HTML jest w stanie ją sprawdzić przy
pomocy copy&paste. Upierdliwe, ale się da.

>   Jedyne co musiałby zrobić, to zamienić każdą podwójną spację na  
> Załatwia to jednolinijkowiec typu (pewnie można lekko podszlifować):
> cat plik | perl -pe 's/\s{2}/ /g'

>   Niestety, szybka weryfikacja w www-pl/philosophy i widzę, że tak 
> prosto się nie da:
> grep "  " *.pl.po - tekst angielski jest obecny i ma 2 spacje.
> grep "   " *.pl.po - 3 też nie rozwiązują sprawy.

>   Można kombinować w stronę:
> egrep "\S\s\s\s\S" *.pl.po (nie biały znak, trzy spacje (białe znaki),
> nie biały znak), ale też nie jest idealnie.

Trywialnie się nie da, bo pliki gettexta są bardziej skomplikowane.

Podsumowując moje zdanie, wg mnie problem jest mały, choć upierdliwy
(przynajmniej copy&paste przy sprawdzaniu pisowni w jakimś edytorze
HTML), natomiast proponowany zysk jest chyba jeszcze mniejszy, a
kłopotów przy okazji sporo.

Tak na marginesie, jeśli idziemy tropem programu, to podobnej
trudności będzie napisanie programu, który by zamieniał odpowiednie
kombinacje słów jedno plus wieloliterowych na litera plus   plus
drugie słowo. Tutaj widzę nieco większe zastosowanie. Czy ktoś jest
chętny do napisania odpowiedniego softu?

-- 
pozdrawiam
Sylwester Zarębski




reply via email to

[Prev in Thread] Current Thread [Next in Thread]