Александър Шопов wrote:
> Естествено, че може да се направи и друг еквивалент, но в стандартната му форма могат евенруално да се > бистрят някакви оптимизации.Здравей Румене,Ето и поправките, които съм нанесъл. Виж дали ти се нравят. Накратко: I. Служебна информация 1. Стандартният израз за множествените форми за езици като нашия е: Plural-Forms: nplurals=2; plural=n != 1;\n
Съгласен, само ще го оградя в скоби. Предишното бе както пише из разни примери.
2. FSF предпочитат авторските права да се дават по години.2002-2007 би трябвало да значи 2002, 2003, 2004, 2005, 2006, 2007 и те предпочитат 2-я вариант.
Тук за годините се затрудних. Липсва в pot-файла. Май ще остане само 2007.Редове от коментара в началото следват pot-файла и не ми се иска да променям последователността им.
II. Съдържание1. Usage в повечето конзолни програми съм го давал като употреба и мисля, че и другите преводачи го предпочитат.
Прието.
2. Внимавай с пълния член
А тук колко въпроси има ... и кога да се членува. Например: заместване на непреобразуваемите байтове. Мисля, че не трябва да го членуваме.
3. Като преведеш - прозинеси си фразата, може да усетиш, че на български обикновено същото се казва с по-различен словоред (без да е грешен твоя, но има и по-добър)
Е българския е доста свободен. Ще приема по-използван словоред.
4. Съобразявай се с това, че превеждаш конзолна програма. Горе долу стандартният ред е широк 80 знака - гледай ти да правиш пренасянето на ред, че иначе резултатът е лош. Когато съобщенията съдържат форматиращи низове (напр. %s) виж дали е възможно да пресметнеш максималната дължина на низа и така да направиш пренасянето. (при теб беше възможно например в съобщенията с"%s argument: The ...%s е едно от --unicode-subst --byte-subst --widechar-subst - виждаш най-дългото и действаш
И кода и документацията гледах, но май се иска да се тества програмата.Общо взето формата е като за printf, със само един форматиращ аргумент за цяло число.
Това е една от причините да не го напиша в множествено число. Например, \%04x, би трябва да е валиден формат за iconv 1.12. Ако е невалиден формата ще се получи съобщение:iconv: При аргумента "--byte-subst": не са позволени директиви за форматиране с
променлива ширина. Затова, ако няма нищо против, ще го оставя началото както преди: "%s аргумент: не е позволена директива за форматиране с размер."Също така, това е съобщение за грешка, и като такова, смятам, че не трябва да има символи за нов ред.
Относно: msgid "%s argument: The format string consumes more than one argument: %u argument." Ако зададем --byte-subst="\%x\%o\%x" при предложения превод ще се получи нещо като: "iconv: При аргумента "--byte-subst": форматиращият низ използва повече от един
аргумент — 3." Затова предлагам да се придържаме по-близко до оригинала:msgstr[0] "%s аргумент: форматиращият низ използва повече от един аргумент: %u аргумент." msgstr[1] "%s аргумент: форматиращият низ използва повече от един аргумент: %u аргумента."
5. Сложил съм български кавички, многоточие и тире - просто потребителите на превод на конзолни програми най-вероятно имат добре кирилизирана конзола в UTF-8 (не е задължително, но просто такава е аудиторията).
Отхвърлено - не са валидни символи в ISO кирилица.Кодирането на po файла в UTF-8, не означава, че ще работи само на терминали в UTF-8. Тук има още един проблем: iconv е конзолно приложение и на някой ОС трябва да ползва IBM866 или IBM855 (зависи от версията на ОС), а не CP1251. Изключвам разни странни chcp като 359.
Последното, обаче, не е свързано с превода.
6. Symbol и character в твоя случай са "знак".
От една страна писмен знак ми се видя дълго. От друга страна, казваме низ от символи(string) или символен низ.От трета страна има "невидими" знаци, например, за нов ред, разни контролни знаци (!?!?).
Контролен знак не ми се вижда подходящо. В този контекст, символ е по-общото. Засега в новата версия е оставено знак.
7. Вместо кодировка предпочитам (пък май и другите) кодиране.
ОК.
8. В твоя файл има много коментари към преводача, четеш ги, нали?
:), а и кода около коментара помага.
Ами, то автора на iconv и gettext е един и същ и предполагам, ще стигнат и до там.III. ВъпросПодобни съобщения има и в glibc - iconv и сие? Искаш ли след това да пробваме дали съобщенията ти стават за там или не ти се занимава/нямаш време?
Или за преводите в libc, май, отговаряше някой с адрес в redhat ? Признавам си, че не съм гледал libc от ... да кажа само отдавна.Ако автора на libiconv, не обновява преводите в libc, няма проблем да направим превод, специфичен за libc.
Поздрави: ал_шопов
Към писмото е прикачен архив libiconv-bg.po.tar.gz с обновената версия, както и unified diff към пердишната.
Все още съм раздвоен за знак<->символ. Румен
libiconv-bg.po.tar.gz
Description: application/gzip
_______________________________________________ Dict mailing list [email protected] http://zver.fsa-bg.org/cgi-bin/mailman/listinfo/dict
