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

[Lub_Lau]

Kdyz jsem si prohlizel programy pro linux, tak velice casto narazim 
na prakticky totozna opakujici se mista, zvlaste jde o vypisy 
programu na obrazovku, at uz jde o ruzna systemova hlaseni, ale 
predevsim napovedu.
Uroven napovedy u jednotlivych programu je velmi ruzna, nekde jde 
o jednu radku, nekde se nevyskytuje nic a naopak nekde nam 
vyskoci ten samy text, ktery se nam objevuje v manualovych 
strankach.
Protoze pocestovani je znacne narocna vec, znamena to prelozit 
jak manual, tak i systemova hlaseni a napovedu, ktera se 
vyskytuje ve zdrojovem textu. 
Pro ulehceni prekladani vsech programu, doporucuji nasledujici 
kroky, jak si ulehcit praci, jak zmensit velikost programu a pritom 
zvysit prehlednost systemu. Bohuzel to muze mit za nasledek 
zruseni casti souboru v adresarich manualovych souboru, popr. 
zavedeni novych pristupu a zmeny adresarove struktury 
soucasneho linuxu.

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.

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.
 
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.

Z uvedeneho vyplyva, ze soucasny osvedceny zpusob pouzivani 
programu man, lynx a format vypisu napovedy konkretniho 
programu je nutno prehodnotit. 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.

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 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 % 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.

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.


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.

-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.

V praxi jsem  se setkal s nekolika pripady, ovsem bez zdrojovych 
textu, ktere by odpovidaly tomuto zameru, jenze neslo o LINUX. 
Pokud nekde znate vhodne typy, ktere jsou zvcetne zdrojovych 
textu a zaroven nemusi jit jenom o LINUX. Mate nekdo dobre 
odkazy, kterich tvurci  jiz znaji a vedi, ze se anglictina nepouziva 
vsude, kde jsou pristupni k uzivatelum a umoznuji jednoduchy 
prechod z jednoho jazyka do druheho.

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. 

S pozdravem LLau.