Jak resit multinarodni programy???, lokalizace - man, lynx a help

[Michal Krause]

On 12/23/99 01:08, Lub_Lau wrote:

> 1. pri pozadavku vypisu napovedy napr.
>   program -h 
> popr.  program --help
> 
> nahradit ve zdrojovem textu 
> 
> printf( "Urcita napoveda" );
> 
> nahradit spustenim externiho programu lynx nebo popr. man s 
> prislusnym parametrem odkazujici na htm soubor napovedy, popr. 
> manualovou stranku.

To je hloupost. Preci nebudu spoustet externi program (coz je navic dost
obskurni uz samo o sobe) pokazde, kdyz si zrovna nemuzu vzpomenout,
jestli rekurzivni kopirovani dela u cp parametr -r nebo -R

-h nebo --help existuje proto, abyste rychle ziskal zakladni prehled o
tom, co a jak program dela, pokud to chci studovat hloubeji jdu do manu,
infa nebo treba do pribalene dokumentace k programu v jinem formatu
 
> Vysledkem je jednoznacne zmenseni vlastniho programu, ale 
> hlavne dochazi k uspore casu pri prekladech napovedy primo ve 
> zdrojovem textu, ktery je takto z tohoto textu naprosto vyloucen.

Program, ktery ma kompletni dlouho napovedu v sobe je zvrhlost. Ale
vyjmutim te male napovedy o velikosti cca 500 az 4000 znaku usetrite pri
prekladu asi tak nulu nula nic casu.
 
> Osobne se domnivam, ze preklady napovedy, tak jak je zname v 
> soucasne podobe nasvedcuji tomu, ze k tomuto se pristupuje 
> velice okrajove a napoveda u nekterych programu prakticky ma 
> nulovou schopnost napovedet uzivateli o vlastnich funkcich 
> programu, ba naopak jej nuti si spustit man, ktery je vlastne jen 
> dalsim zbytecnym programem, neb o toto se muze starat lynx 
> pokud by manualy, helpy, byly ve pouze formatu html.

Jak jsem psal, help z prikazove radky je jenom takova pomucka, takze ta
okrajovost neni dusledkem lenosti programatora (vetsinou), ale zamerem.

Nahrazovat man lynxem je podle meho soudu rovnez ponekud zvrhle, uz
jenom proto, ze man je v unixu zkratka zachytnym bodem, na nejz se lze
vzdy a vsude spolehnout. Zkratka me by se nelibilo, kdyby se tady
pouzival man, tamhle lynx, tuhle irixman a jinde
extendedmanualpageviewerwithsomeniftyfeatures

> Z uvedeneho vyplyva, ze soucasny osvedceny zpusob pouzivani programu
> man, lynx a format vypisu napovedy konkretniho programu je nutno
> prehodnotit.

Me tedy z toho zatim nic takoveho nevyplyva.

> Vyhazet ze systemu duplicitni informace, ktere se vyskytuji na vice
> mistech v ruzne podobe s prakticky totoznym mnozstvim informace. Pro
> urcitou zpetnou kompatibilitu se domnivam, ze program man je ze
> systemu nutne vyhodit, avsak jeho cast zaclenit do lynxu, tak aby lynx
> umoznoval otevrit i soubory pro man. Zaroven je dle tohoto nutne
> manualove stranky, pokud nektere neexistuji v html podobe prevest do
> formatu html.

S tou duplictou lze souhlasit. Ale nechapu tu vetu, ze "v ramci
zachovani kompatibility je nutne man ze systemu vyhodit". V ramci
zachovani kompatibility je nutne man v systemu ponechat. Slucovat funkce
dvou a vice programu do jedne velke mrchy je metoda jinych
taky-operacnich systemu. 

> Osobne uznavam format html jako naprosto universalni a snadno
> prenositelny. Domnivam se dale, ze do tento format se musi stat
> zakladnim formatem pro textove a hypertextove soubory v Linuxu i
> ostatnich operacnich systemech i kdyz ma sve urcite nevyhody proti
> specialnim formatum souboru. Proto privitam odkazy na lepe vyresene
> prevodni programy, nez ze si to clovek musi obcas napsat, zvlaste ze
> souboru ps, pdf a jinych - do formatu  html. Samozrejme nemusite se
> mnou souhlasit,  neb si uvedomuji jak je tezka zmena velkych archivu

To mate pravdu, nemusim a taky nesouhlasim. A dovolim si podotknout, ze
kdyz uz bych volil nejaky format pro dokumentaci, tak by to rozhodne
nebylo HTML, ale XML. Myslim, ze u dokumentace je docela dulezite oddeleni
obsahu a formy, kteryzto pozadavek HTML nesplnuje.

> provadenych ve specialnim formatu souboru do jinych formatu, jak jsou
> tyto prevody casove narocne,    ale pokud napr. v jinem operacnim
> systemu existuje pouze 1 program na prohlizeni a velice spatny prevod
> na format, ktery je v linuxu bezne pouzivan, je to jenom znamkou toho,
> ze zde neni mnohe doreseno. Je to podobne jako s JAVOU, ta z 80 %

No ja nevim. Man je tady uz tricet let. HTML existuje asi ctvrtinu te
doby a uz je na odchodu, protoze se ukazalo, ze je v mnoha ohledech
nevhodne a nedostacujici. Podle me zejmena v tom, ze prave mota obsah a
formu do jednoho pelmelu.

> chodi  ve vsech operacnich systemech (minimalne 5 x pomaleji). Takze
> by to melo existovat i v ostatnich oblastech textovych a datovych
> souboru a ne jenom pro uzky okruh uzivatelu jednoho specialniho
> programu a jednoho operacniho systemu a to nektere formaty, ktere se
> pouzivaji v linuxu jsou.

Zadny format podle me neni ciste linuxovou zalezitosti. Naprosta vetsina
z nich je zdedena z Unixu a pokud to vezmu z hlediska poctu operacnich
systemu, tak jsou to formaty podporovane v naproste vetsine. Az na jednu
vyjimku, ktera ma shodou okolnosti momentalne nejvice instalaci na
svete.
 
> Soucasny pristup, kdy uzivatele ruznych operacnich systemu vzajemne
> spolu vedou spory a povazuji jen ten svuj operacni system za jediny
> spravny a ten nejlepsi, ma nakonec za nasledek naprostou a totalni
> nejednost. Vysledkem je pote totalni neprehlednost a komplikovanost
> prevodu textovych a datovych souboru z jednoho oper. systemu do
> druheho, popr. nemoznost prevodu.

To je naprosty nesmysl. Jedine formaty, ktere nejsou snadno prenositelne
mezi platformami jsou ty proprietarni a komercni. A za to nemuzou
zabomysi valky uzivatelu, ale subjekty, ktere je stvorily. Micro$oft
nema nejmensi duvod, aby data z Office sly zobrazit (nebo nejde boze
editovat) na jinych platformach, natoz v konkurencnich produktech.
Stejne tak dalsi komercni spolecnosti nic nenuti, aby uzivaly otevrene a
zdokumentovane datove formaty. A nic je nutit nebude, dokud se my,
uzivatele, neozveme, dokud si budeme nechavat veset na nos buliky o tom,
ze tem firmam zalezi na nasem blahu.

> Protokolovani cinnosti libovolneho programu, tak jak je to zavedeno u
> nekterych programu, tak zavest jako zaklad. Opetne to souvisi s
> vypisem textoveho hlaseni programu pri jeho cinnosti na monitor.
> Nejprve zacnu nevyhodou tohoto reseni, a to je opet mirne zpomaleni
> cinnosti programu, a ted budou nasledovat pouze vyhody. Navrhovany
> princip: -spusteny program bude provadet pouze dany ukol, ke kteremu
> je urcen. -chybova a informacni textova hlaseni na obrazovku nebo
> souboru, ktere jsou v soucasnosti ve zaclenena do vlastniho programu,
> bude provadet jiny program pro vsechny nebo urcitou skupinu programu
> spolecne bud primo na obrazovku nebo v pomocnem protokolovem okne.
> Popr. protokol cinnosti programu bude bude mozne vypisovat na
> obrazovku, do souboru, na tiskarnu nebo vypis se nebude konat vubec.

Takze syslog. Nic noveho pod sluncem. Nevidim ale duvod, proc by mel
kazdy znak, ktery nekdo v systemu vyplodi projit pres syslog. 

> -vsechna hlaseni budou pro tuto skupinu programu ulozena ve snadno
> editovatelnem textovem souboru, kde pod prislusnym cislem na radku
> bude prislusne hlaseni. Snadno editovatelny soubor se snadno preklada,
> je podstatny rozdil prekladat nahodne rouztrousene vypisy ve zdrojovem
> textu nebo prelozit jeden soubor pro vsechny soubory ve skupine.
> Narocnost na hardware, takto universalne multinarodne tvorenych
> programu je prakticky totozna se soucasnym stavem. Ma to vsak jeden
> nepriznivy efekt. Znamena to totalne prepsat vsechny zdrojove texty
> LINUXu.

Opet jste vedle, jak ten javor. Naprosta vetsina programu dnes jiz
pouziva tzv. katalogy, ktere delaji presne to, co jste popsal. Pouze
pomoci nastaveni locales (a samozrejme pri pritomnosti patricneho
katalogu) komunikuje program v ruznych jazycich. Zkuste si treba

LC_ALL=de cp

Katalogy ve zdrojove podobe jsou ve tvaru

msgid "original message"
msgstr "originalni zprava"

takze se dobre prekladaji.

Mimochodem, kdyz mluvite o zdrojovych kodech Linuxu, myslite aplikace
nebo jadro? Asi aplikace, rekl bych.

> V praxi jsem  se setkal s nekolika pripady, ovsem bez zdrojovych
> textu, ktere by odpovidaly tomuto zameru, jenze neslo o LINUX. Pokud

Ja jsem se s tim naopak poprve setkal az na Linuxu :)

> Je samozrejme, ze s navrhy nebudete souhlasit, i kdyz v urcitych
> ohledech muzou mit v konecnem dusledku snizeni obsazeneho prostoru
> disku, snizeni fragmentace,  jak mnozstvim souboru, tak redukci jejich
> velikosti.  zvyseni prehlednosti systemu a jine vedlejsi prinosy,
> zvlaste pro tak male zeme jako je CR, nebo SR. 

Abych to shrnul, podle me jste z poloviny navrhl veci, ktere povazuji za
nevhodne az nesmyslne a z druhe poloviny jste vynalezal kolo, takze
prinos je veskrze minimalni. Asi jste to myslel dobre, ale vysledek je k
nicemu. Toliko muj nazor.

S pozdravem
--
Michal Krause                                                      /\
ICQ: 7665279            Informace (nejenom) ze sveta Linuxu     /\/  \
email: mike na navrcholu.cz ______ http://www.root.cz/ ______ NAVRCHOLU.cz

Co napsat do signatury, aby to nikoho nepohorsilo? Snad jedine nejakou
obecne znamou pravdu. Doufam, ze vsichni vite, ze tucnak je bylozrava ryba.