https://www.altlinux.org/api.php?action=feedcontributions&user=VladislavZavjalov&feedformat=atomALT Linux Wiki - Вклад [ru]2024-03-29T10:03:17ZВкладMediaWiki 1.38.2https://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8982Alterator/AlteratorNetIptables2009-02-06T14:35:52Z<p>VladislavZavjalov: /* В соответствии с этими параметрами производятся следующие настройки системы: */</p>
<hr />
<div>== alterator-net-iptables >= 1.0 ==<br />
<br />
<br />
Модуль хранит свое состояние в отдельном файле и из него настраивает систему "в одну сторону". <br />
<br />
Имеется скрипт iptables_helper (с достаточно человеколюбивым интерфейсом) умеющий читать и писать конфигурацию и настраивать систему, а также тривиальный модуль альтератора, который его использует. <br />
<br />
=== Мы работаем со следующими параметрами: ===<br />
<br />
* режим работы (firewall/gateway)<br />
* список внешних интерфейсов<br />
* список открытых снаружи сервисов<br />
* список открытых снаружи портов<br />
* дополнительные опции (сейчас поддерживается только запись правил для ulogd)<br />
<br />
=== В соответствии с этими параметрами производятся следующие настройки системы: ===<br />
* iptables -- включен всегда<br />
* forwarding -- включен всегда<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}}:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
-i <интейрфейс> -p <протокол> --dport <порт> -j ACCEPT # для всех открытых сервисов и <br />
# портов, для всех внешних интерфейсов<br />
-i <интерфейс> -j DROP # для всех внешних интерфейсов<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}}:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
<br />
* для каждой пары внутренних интерфейсов в {{path|/etc/net/ifaces/default/fw/iptables/filter/FORWARDING}}:<br />
-i $i1 -o $i2 -j DROP<br />
<br />
* если режим работы gateway, то в {{path|/etc/net/ifaces/default/fw/iptables/nat/POSTROUTING}}:<br />
-o <внешн.интерфейс> -j MASQUERADE # для каждой пары внутненний-внешний интерфейс<br />
<br />
=== Кроме того ===<br />
* service iptables не существует, все работает через etcnet + efw.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8981Alterator/AlteratorNetIptables2009-02-06T14:35:25Z<p>VladislavZavjalov: /* В соответствии с этими параметрами производятся следующие настройки системы: */</p>
<hr />
<div>== alterator-net-iptables >= 1.0 ==<br />
<br />
<br />
Модуль хранит свое состояние в отдельном файле и из него настраивает систему "в одну сторону". <br />
<br />
Имеется скрипт iptables_helper (с достаточно человеколюбивым интерфейсом) умеющий читать и писать конфигурацию и настраивать систему, а также тривиальный модуль альтератора, который его использует. <br />
<br />
=== Мы работаем со следующими параметрами: ===<br />
<br />
* режим работы (firewall/gateway)<br />
* список внешних интерфейсов<br />
* список открытых снаружи сервисов<br />
* список открытых снаружи портов<br />
* дополнительные опции (сейчас поддерживается только запись правил для ulogd)<br />
<br />
=== В соответствии с этими параметрами производятся следующие настройки системы: ===<br />
* iptables -- включен всегда<br />
* forwarding -- включен всегда<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}}:<br />
-P DROP<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
-i lo -j ACCEPT<br />
-i <интейрфейс> -p <протокол> --dport <порт> -j ACCEPT # для всех открытых сервисов и <br />
# портов, для всех внешних интерфейсов<br />
-i <интерфейс> -j DROP # для всех внешних интерфейсов<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}}:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
<br />
* для каждой пары внутренних интерфейсов в {{path|/etc/net/ifaces/default/fw/iptables/filter/FORWARDING}}:<br />
-i $i1 -o $i2 -j DROP<br />
<br />
* если режим работы gateway, то в {{path|/etc/net/ifaces/default/fw/iptables/nat/POSTROUTING}}:<br />
-o <внешн.интерфейс> -j MASQUERADE # для каждой пары внутненний-внешний интерфейс<br />
<br />
=== Кроме того ===<br />
* service iptables не существует, все работает через etcnet + efw.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8980Alterator/AlteratorNetIptables2009-02-06T14:34:42Z<p>VladislavZavjalov: /* В соответствии с этими параметрами производятся следующие настройки системы: */</p>
<hr />
<div>== alterator-net-iptables >= 1.0 ==<br />
<br />
<br />
Модуль хранит свое состояние в отдельном файле и из него настраивает систему "в одну сторону". <br />
<br />
Имеется скрипт iptables_helper (с достаточно человеколюбивым интерфейсом) умеющий читать и писать конфигурацию и настраивать систему, а также тривиальный модуль альтератора, который его использует. <br />
<br />
=== Мы работаем со следующими параметрами: ===<br />
<br />
* режим работы (firewall/gateway)<br />
* список внешних интерфейсов<br />
* список открытых снаружи сервисов<br />
* список открытых снаружи портов<br />
* дополнительные опции (сейчас поддерживается только запись правил для ulogd)<br />
<br />
=== В соответствии с этими параметрами производятся следующие настройки системы: ===<br />
* iptables -- включен всегда<br />
* forwarding -- включен всегда<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}} перезаписывается:<br />
-P DROP<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
-i lo -j ACCEPT<br />
-i <интейрфейс> -p <протокол> --dport <порт> -j ACCEPT # для всех открытых сервисов и <br />
# портов, для всех внешних интерфейсов<br />
-i <интерфейс> -j DROP # для всех внешних интерфейсов<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}} перезаписывается:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
<br />
* для каждой пары внутренних интерфейсов в {{path|/etc/net/ifaces/default/fw/iptables/filter/FORWARDING}}:<br />
-i $i1 -o $i2 -j DROP<br />
<br />
* если режим работы gateway, то в {{path|/etc/net/ifaces/default/fw/iptables/nat/POSTROUTING}}:<br />
-o <внешн.интерфейс> -j MASQUERADE # для каждой пары внутненний-внешний интерфейс<br />
<br />
=== Кроме того ===<br />
* service iptables не существует, все работает через etcnet + efw.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8979Alterator/AlteratorNetIptables2009-02-06T14:33:20Z<p>VladislavZavjalov: /* alterator-net-iptables >= 1.0 */</p>
<hr />
<div>== alterator-net-iptables >= 1.0 ==<br />
<br />
<br />
Модуль хранит свое состояние в отдельном файле и из него настраивает систему "в одну сторону". <br />
<br />
Имеется скрипт iptables_helper (с достаточно человеколюбивым интерфейсом) умеющий читать и писать конфигурацию и настраивать систему, а также тривиальный модуль альтератора, который его использует. <br />
<br />
=== Мы работаем со следующими параметрами: ===<br />
<br />
* режим работы (firewall/gateway)<br />
* список внешних интерфейсов<br />
* список открытых снаружи сервисов<br />
* список открытых снаружи портов<br />
* дополнительные опции (сейчас поддерживается только запись правил для ulogd)<br />
<br />
=== В соответствии с этими параметрами производятся следующие настройки системы: ===<br />
* iptables -- включен всегда<br />
* forwarding -- включен всегда<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}} перезаписывается:<br />
-P DROP<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
-i lo -j ACCEPT<br />
-i <интейрфейс> -p <протокол> --dport <порт> -j ACCEPT # для всех открытых сервисов и портов, для всех внешних интерфейсов<br />
-i <интерфейс> -j DROP # для всех внутренних интерфейсов<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}} перезаписывается:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
<br />
* для каждой пары внутренних интерфейсов в {{path|/etc/net/ifaces/default/fw/iptables/filter/FORWARDING}}:<br />
-i $i1 -o $i2 -j DROP<br />
<br />
* если режим работы gateway, то в {{path|/etc/net/ifaces/default/fw/iptables/nat/POSTROUTING}}:<br />
-o <внешн.интерфейс> -j MASQUERADE # для каждой пары внутненний-внешний интерфейс<br />
<br />
<br />
=== Кроме того ===<br />
* service iptables не существует, все работает через etcnet + efw.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8978Alterator/AlteratorNetIptables2009-02-06T14:32:43Z<p>VladislavZavjalov: </p>
<hr />
<div>== alterator-net-iptables >= 1.0 ==<br />
<br />
<br />
Модуль хранит свое состояние в отдельном файле и из него настраивается система "в одну сторону". <br />
<br />
Имеется скрипт iptables_helper (с достаточно человеколюбивым интерфейсом) умеющий читать и писать конфигурацию и настраивать систему, а также тривиальный модуль альтератора, который его использует. <br />
<br />
=== Мы работаем со следующими параметрами: ===<br />
<br />
* режим работы (firewall/gateway)<br />
* список внешних интерфейсов<br />
* список открытых снаружи сервисов<br />
* список открытых снаружи портов<br />
* дополнительные опции (сейчас поддерживается только запись правил для ulogd)<br />
<br />
=== В соответствии с этими параметрами производятся следующие настройки системы: ===<br />
* iptables -- включен всегда<br />
* forwarding -- включен всегда<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}} перезаписывается:<br />
-P DROP<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
-i lo -j ACCEPT<br />
-i <интейрфейс> -p <протокол> --dport <порт> -j ACCEPT # для всех открытых сервисов и портов, для всех внешних интерфейсов<br />
-i <интерфейс> -j DROP # для всех внутренних интерфейсов<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}} перезаписывается:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
<br />
* для каждой пары внутренних интерфейсов в {{path|/etc/net/ifaces/default/fw/iptables/filter/FORWARDING}}:<br />
-i $i1 -o $i2 -j DROP<br />
<br />
* если режим работы gateway, то в {{path|/etc/net/ifaces/default/fw/iptables/nat/POSTROUTING}}:<br />
-o <внешн.интерфейс> -j MASQUERADE # для каждой пары внутненний-внешний интерфейс<br />
<br />
<br />
=== Кроме того ===<br />
* service iptables не существует, все работает через etcnet + efw.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8977Alterator/AlteratorNetIptables2009-02-06T14:22:28Z<p>VladislavZavjalov: /* = В соответствии с этими параметрами производятся следующие настройки системы: */</p>
<hr />
<div>'''alterator-net-iptables'''<br />
<br />
''Проект, по результатам разговора с vitty@''<br />
<br />
<br />
Модуль хранит свое состояние в отдельном файле и из него настраивается система "в одну сторону". <br />
<br />
Имеется скрипт iptables_helper (с достаточно человеколюбивым интерфейсом) умеющий читать и писать конфигурацию и настраивать систему, а также тривиальный модуль альтератора, который его использует. <br />
<br />
=== Мы работаем со следующими параметрами: ===<br />
<br />
* режим работы (firewall/gateway)<br />
* список внешних интерфейсов<br />
* список открытых снаружи сервисов<br />
* список открытых снаружи портов<br />
* дополнительные опции (сейчас поддерживается только запись правил для ulogd)<br />
<br />
=== В соответствии с этими параметрами производятся следующие настройки системы: ===<br />
* iptables -- включен всегда<br />
* forwarding -- включен всегда<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}} перезаписывается:<br />
-P DROP<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
-i lo -j ACCEPT<br />
-i <интейрфейс> -p <протокол> --dport <порт> -j ACCEPT # для всех открытых сервисов и портов, для всех внешних интерфейсов<br />
-i <интерфейс> -j DROP # для всех внутренних интерфейсов<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}} перезаписывается:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
<br />
* для каждой пары внутренних интерфейсов в {{path|/etc/net/ifaces/default/fw/iptables/filter/FORWARDING}}:<br />
-i $i1 -o $i2 -j DROP<br />
<br />
* если режим работы gateway, то в {{path|/etc/net/ifaces/default/fw/iptables/nat/POSTROUTING}}:<br />
-o <внешн.интерфейс> -j MASQUERADE # для каждой пары внутненний-внешний интерфейс<br />
<br />
<br />
=== Кроме того ===<br />
* service iptables не существует, все работает через etcnet + efw.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8976Alterator/AlteratorNetIptables2009-02-06T14:22:17Z<p>VladislavZavjalov: </p>
<hr />
<div>'''alterator-net-iptables'''<br />
<br />
''Проект, по результатам разговора с vitty@''<br />
<br />
<br />
Модуль хранит свое состояние в отдельном файле и из него настраивается система "в одну сторону". <br />
<br />
Имеется скрипт iptables_helper (с достаточно человеколюбивым интерфейсом) умеющий читать и писать конфигурацию и настраивать систему, а также тривиальный модуль альтератора, который его использует. <br />
<br />
=== Мы работаем со следующими параметрами: ===<br />
<br />
* режим работы (firewall/gateway)<br />
* список внешних интерфейсов<br />
* список открытых снаружи сервисов<br />
* список открытых снаружи портов<br />
* дополнительные опции (сейчас поддерживается только запись правил для ulogd)<br />
<br />
=== В соответствии с этими параметрами производятся следующие настройки системы: ==<br />
* iptables -- включен всегда<br />
* forwarding -- включен всегда<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}} перезаписывается:<br />
-P DROP<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
-i lo -j ACCEPT<br />
-i <интейрфейс> -p <протокол> --dport <порт> -j ACCEPT # для всех открытых сервисов и портов, для всех внешних интерфейсов<br />
-i <интерфейс> -j DROP # для всех внутренних интерфейсов<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}} перезаписывается:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
<br />
* для каждой пары внутренних интерфейсов в {{path|/etc/net/ifaces/default/fw/iptables/filter/FORWARDING}}:<br />
-i $i1 -o $i2 -j DROP<br />
<br />
* если режим работы gateway, то в {{path|/etc/net/ifaces/default/fw/iptables/nat/POSTROUTING}}:<br />
-o <внешн.интерфейс> -j MASQUERADE # для каждой пары внутненний-внешний интерфейс<br />
<br />
<br />
=== Кроме того ===<br />
* service iptables не существует, все работает через etcnet + efw.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8975Alterator/AlteratorNetIptables2009-02-06T14:20:58Z<p>VladislavZavjalov: </p>
<hr />
<div>'''alterator-net-iptables'''<br />
<br />
''Проект, по результатам разговора с vitty@''<br />
<br />
<br />
Модуль хранит свое состояние в отдельном файле и из него настраивается система "в одну сторону". <br />
<br />
Имеется скрипт iptables_helper (с достаточно человеколюбивым интерфейсом) умеющий читать и писать конфигурацию и настраивать систему, а также тривиальный модуль альтератора, который его использует. <br />
<br />
Мы работаем со следующими настройками:<br />
<br />
* режим работы (firewall/gateway)<br />
* список внешних интерфейсов<br />
* список открытых снаружи сервисов<br />
* список открытых снаружи портов<br />
* дополнительные опции (сейчас поддерживается только запись правил для ulogd)<br />
<br />
В соответствии с этими параметрами производятся следующие настройки:<br />
* iptables -- включен всегда<br />
* forwarding -- включен всегда<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}} перезаписывается:<br />
-P DROP<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
-i lo -j ACCEPT<br />
-i <интейрфейс> -p <протокол> --dport <порт> -j ACCEPT # для всех открытых сервисов и портов, для всех внешних интерфейсов<br />
-i <интерфейс> -j DROP # для всех внутренних интерфейсов<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}} перезаписывается:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
<br />
* для каждой пары внутренних интерфейсов в {{path|/etc/net/ifaces/default/fw/iptables/filter/FORWARDING}}:<br />
-i $i1 -o $i2 -j DROP<br />
<br />
* если режим работы gateway, то в {{path|/etc/net/ifaces/default/fw/iptables/nat/POSTROUTING}}:<br />
-o <внешн.интерфейс> -j MASQUERADE # для каждой пары внутненний-внешний интерфейс<br />
<br />
<br />
== Устаревшее ==<br />
<br />
=== Процедура сброса состояния системы (в частности, при инсталляции) ===<br />
* из {{path|/etc/net/ifaces/default/fw/iptables/filter/{INPUT/OUTPUT{{)}}}} стираются строчки, содержащие {{term|"-P"}}, {{term|"-j DROP"}}, {{term|"-j ACCEPT"}}' (строчка {{term|"ULOGD"}} при этом сохраняется, интересно, нужно ли тут сохранять какие-то ещё чужие строчки?)<br />
* в {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}} дописывается:<br />
-P DROP<br />
-i lo -j ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
<br />
* в {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}}:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
* в {{path|/etc/net/ifaces/default/fw/options}} перезаписываются параметры:<br />
FW_TYPE="iptables"<br />
IPTABLES_HUMAN_SYNTAX=no<br />
* в {{path|/etc/net/ifaces/default/options}}:<br />
CONFIG_FW=yes<br />
* таким образом все порты на всех интерфейсах закрыты, firewall включён<br />
<br />
=== Модуль определяет текущее состояние ===<br />
* определяется default policy (сперва из {{path|/etc/net/ifaces/default/fw/options}}, потом из {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}}).<br />
** Если {{term|ACCEPT}} — все интерфейсы считаются внутренними<br />
** Если {{term|DROP}} — дополнительно определяем внутренние интерфейсы по строчкам {{term|-i <имя> -j ACCEPT}}<br />
* определяем дополнительно открытые сервисы (группы портов) и отдельные порты — по строчкам вида '{{term|-p <протокол> --dport <порт> -j ACCEPT}}' (это уже есть в существующем модуле)<br />
<br />
=== Модуль перезаписывает состояние ===<br />
* происходит сброс конфигурационных файлов в начальное состояние (см. выше)<br />
* в INPUT для всех внутренних интерфейсов пишется '{{term|-i <имя> -j ACCEPT}}'<br />
* в INPUT записываются строчки для всех дополнительно открытых наружу сервисов (без указания интерфейсa) '{{term|-p <протокол> --dport <порт> -j ACCEPT}}'<br />
* перезагружаем правила: {{cmd|efw restart}}<br />
<br />
=== Интерфейс ===<br />
* выбор внутренних интерфейсов<br />
* выбор открытых наружу сервисов<br />
* ввод открытых наружу дополнительных портов<br />
<br />
=== Кроме того ===<br />
* service iptables не существует, все работает через etcnet + efw.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8822Alterator/AlteratorNetIptables2009-02-02T12:09:20Z<p>VladislavZavjalov: </p>
<hr />
<div>'''alterator-net-iptables'''<br />
<br />
''Проект, по результатам разговора с vitty@''<br />
<br />
<br />
Модуль хранит свое состояние в отдельном файле и из него перезаписывает все правила iptables. Параметры, с которыми мы работаем:<br />
* список внутренних интерфейсов<br />
* список открытых наружу сервисов<br />
* список открытых наружу портов<br />
* NAT (вкл/выкл)<br />
* ULOGD (вкл/выкл)<br />
<br />
В соответствии с этими параметрами производятся следующие настройки:<br />
* iptables -- включен всегда<br />
* forwarding -- включен всегда<br />
<br />
* в {{path|/etc/net/ifaces/default/fw/options}} устанавливается:<br />
FW_TYPE="iptables"<br />
IPTABLES_HUMAN_SYNTAX=no<br />
<br />
* в {{path|/etc/net/ifaces/default/options}} устанавливается:<br />
CONFIG_FW=yes<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}} перезаписывается:<br />
-P DROP<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
-i lo -j ACCEPT<br />
-i <интерфейс> -j DROP # для всех внутренних интерфейсов<br />
что-то ещё, кажется надо было открыть?<br />
-i <интейрфейс> -p <протокол> --dport <порт> -j ACCEPT # для всех открытых сервисов и портов, для всех внешних интерфейсов<br />
<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}} перезаписывается:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
<br />
* если включен NAT, то в {{path|/etc/net/ifaces/default/fw/iptables/nat/POSTROUTING}}:<br />
-i <внутр.интерфейс> -o <внешн.интерфейс> -j MASQ # для каждой пары внутненний-внешний интерфейс<br />
<br />
<br />
== Устаревшее ==<br />
<br />
=== Процедура сброса состояния системы (в частности, при инсталляции) ===<br />
* из {{path|/etc/net/ifaces/default/fw/iptables/filter/{INPUT/OUTPUT{{)}}}} стираются строчки, содержащие {{term|"-P"}}, {{term|"-j DROP"}}, {{term|"-j ACCEPT"}}' (строчка {{term|"ULOGD"}} при этом сохраняется, интересно, нужно ли тут сохранять какие-то ещё чужие строчки?)<br />
* в {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}} дописывается:<br />
-P DROP<br />
-i lo -j ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
<br />
* в {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}}:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
* в {{path|/etc/net/ifaces/default/fw/options}} перезаписываются параметры:<br />
FW_TYPE="iptables"<br />
IPTABLES_HUMAN_SYNTAX=no<br />
* в {{path|/etc/net/ifaces/default/options}}:<br />
CONFIG_FW=yes<br />
* таким образом все порты на всех интерфейсах закрыты, firewall включён<br />
<br />
=== Модуль определяет текущее состояние ===<br />
* определяется default policy (сперва из {{path|/etc/net/ifaces/default/fw/options}}, потом из {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}}).<br />
** Если {{term|ACCEPT}} — все интерфейсы считаются внутренними<br />
** Если {{term|DROP}} — дополнительно определяем внутренние интерфейсы по строчкам {{term|-i <имя> -j ACCEPT}}<br />
* определяем дополнительно открытые сервисы (группы портов) и отдельные порты — по строчкам вида '{{term|-p <протокол> --dport <порт> -j ACCEPT}}' (это уже есть в существующем модуле)<br />
<br />
=== Модуль перезаписывает состояние ===<br />
* происходит сброс конфигурационных файлов в начальное состояние (см. выше)<br />
* в INPUT для всех внутренних интерфейсов пишется '{{term|-i <имя> -j ACCEPT}}'<br />
* в INPUT записываются строчки для всех дополнительно открытых наружу сервисов (без указания интерфейсa) '{{term|-p <протокол> --dport <порт> -j ACCEPT}}'<br />
* перезагружаем правила: {{cmd|efw restart}}<br />
<br />
=== Интерфейс ===<br />
* выбор внутренних интерфейсов<br />
* выбор открытых наружу сервисов<br />
* ввод открытых наружу дополнительных портов<br />
<br />
=== Кроме того ===<br />
* service iptables не существует, все работает через etcnet + efw.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8821Alterator/AlteratorNetIptables2009-02-02T12:07:10Z<p>VladislavZavjalov: </p>
<hr />
<div>'''alterator-net-iptables'''<br />
<br />
''Проект, по результатам разговора с vitty@''<br />
<br />
<br />
Модуль хранит свое состояние в отдельном файле и из него перезаписывает все правила iptables. Параметры, с которыми мы работаем:<br />
* список внутренних интерфейсов<br />
* список открытых наружу сервисов<br />
* список открытых наружу портов<br />
* NAT (вкл/выкл)<br />
<br />
В соответствии с этими параметрами производятся следующие настройки:<br />
* iptables -- включен всегда<br />
* forwarding -- включен всегда<br />
<br />
* в {{path|/etc/net/ifaces/default/fw/options}} устанавливается:<br />
FW_TYPE="iptables"<br />
IPTABLES_HUMAN_SYNTAX=no<br />
* в {{path|/etc/net/ifaces/default/options}} устанавливается:<br />
CONFIG_FW=yes<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}} перезаписывается:<br />
-P DROP<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
-i lo -j ACCEPT<br />
-i <интерфейс> -j DROP # для всех внутренних интерфейсов<br />
что-то ещё, кажется надо было открыть?<br />
-i <интейрфейс> -p <протокол> --dport <порт> -j ACCEPT # для всех открытых сервисов и портов, для всех внешних интерфейсов<br />
<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}} перезаписывается:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
<br />
* если включен NAT, то в {{path|/etc/net/ifaces/default/fw/iptables/nat/POSTROUTING}}:<br />
-i <внутр.интерфейс> -o <внешн.интерфейс> -j MASQ # для каждой пары внутненний-внешний интерфейс<br />
<br />
<br />
== Устаревшее ==<br />
<br />
=== Процедура сброса состояния системы (в частности, при инсталляции) ===<br />
* из {{path|/etc/net/ifaces/default/fw/iptables/filter/{INPUT/OUTPUT{{)}}}} стираются строчки, содержащие {{term|"-P"}}, {{term|"-j DROP"}}, {{term|"-j ACCEPT"}}' (строчка {{term|"ULOGD"}} при этом сохраняется, интересно, нужно ли тут сохранять какие-то ещё чужие строчки?)<br />
* в {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}} дописывается:<br />
-P DROP<br />
-i lo -j ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
<br />
* в {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}}:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
* в {{path|/etc/net/ifaces/default/fw/options}} перезаписываются параметры:<br />
FW_TYPE="iptables"<br />
IPTABLES_HUMAN_SYNTAX=no<br />
* в {{path|/etc/net/ifaces/default/options}}:<br />
CONFIG_FW=yes<br />
* таким образом все порты на всех интерфейсах закрыты, firewall включён<br />
<br />
=== Модуль определяет текущее состояние ===<br />
* определяется default policy (сперва из {{path|/etc/net/ifaces/default/fw/options}}, потом из {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}}).<br />
** Если {{term|ACCEPT}} — все интерфейсы считаются внутренними<br />
** Если {{term|DROP}} — дополнительно определяем внутренние интерфейсы по строчкам {{term|-i <имя> -j ACCEPT}}<br />
* определяем дополнительно открытые сервисы (группы портов) и отдельные порты — по строчкам вида '{{term|-p <протокол> --dport <порт> -j ACCEPT}}' (это уже есть в существующем модуле)<br />
<br />
=== Модуль перезаписывает состояние ===<br />
* происходит сброс конфигурационных файлов в начальное состояние (см. выше)<br />
* в INPUT для всех внутренних интерфейсов пишется '{{term|-i <имя> -j ACCEPT}}'<br />
* в INPUT записываются строчки для всех дополнительно открытых наружу сервисов (без указания интерфейсa) '{{term|-p <протокол> --dport <порт> -j ACCEPT}}'<br />
* перезагружаем правила: {{cmd|efw restart}}<br />
<br />
=== Интерфейс ===<br />
* выбор внутренних интерфейсов<br />
* выбор открытых наружу сервисов<br />
* ввод открытых наружу дополнительных портов<br />
<br />
=== Кроме того ===<br />
* service iptables не существует, все работает через etcnet + efw.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8820Alterator/AlteratorNetIptables2009-02-02T12:06:50Z<p>VladislavZavjalov: </p>
<hr />
<div>'''alterator-net-iptables'''<br />
<br />
''Проект, по результатам разговора с vitty@''<br />
<br />
=== общие идеи ===<br />
<br />
Модуль хранит свое состояние в отдельном файле и из него перезаписывает все правила iptables. Параметры, с которыми мы работаем:<br />
* список внутренних интерфейсов<br />
* список открытых наружу сервисов<br />
* список открытых наружу портов<br />
* NAT (вкл/выкл)<br />
<br />
В соответствии с этими параметрами производятся следующие настройки:<br />
* iptables -- включен всегда<br />
* forwarding -- включен всегда<br />
<br />
* в {{path|/etc/net/ifaces/default/fw/options}} устанавливается:<br />
FW_TYPE="iptables"<br />
IPTABLES_HUMAN_SYNTAX=no<br />
* в {{path|/etc/net/ifaces/default/options}} устанавливается:<br />
CONFIG_FW=yes<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}} перезаписывается:<br />
-P DROP<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
-i lo -j ACCEPT<br />
-i <интерфейс> -j DROP # для всех внутренних интерфейсов<br />
что-то ещё, кажется надо было открыть?<br />
-i <интейрфейс> -p <протокол> --dport <порт> -j ACCEPT # для всех открытых сервисов и портов, для всех внешних интерфейсов<br />
<br />
<br />
* {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}} перезаписывается:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
<br />
* если включен NAT, то в {{path|/etc/net/ifaces/default/fw/iptables/nat/POSTROUTING}}:<br />
-i <внутр.интерфейс> -o <внешн.интерфейс> -j MASQ # для каждой пары внутненний-внешний интерфейс<br />
<br />
<br />
== Устаревшее ==<br />
<br />
=== Процедура сброса состояния системы (в частности, при инсталляции) ===<br />
* из {{path|/etc/net/ifaces/default/fw/iptables/filter/{INPUT/OUTPUT{{)}}}} стираются строчки, содержащие {{term|"-P"}}, {{term|"-j DROP"}}, {{term|"-j ACCEPT"}}' (строчка {{term|"ULOGD"}} при этом сохраняется, интересно, нужно ли тут сохранять какие-то ещё чужие строчки?)<br />
* в {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}} дописывается:<br />
-P DROP<br />
-i lo -j ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
<br />
* в {{path|/etc/net/ifaces/default/fw/iptables/filter/OUTPUT}}:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
* в {{path|/etc/net/ifaces/default/fw/options}} перезаписываются параметры:<br />
FW_TYPE="iptables"<br />
IPTABLES_HUMAN_SYNTAX=no<br />
* в {{path|/etc/net/ifaces/default/options}}:<br />
CONFIG_FW=yes<br />
* таким образом все порты на всех интерфейсах закрыты, firewall включён<br />
<br />
=== Модуль определяет текущее состояние ===<br />
* определяется default policy (сперва из {{path|/etc/net/ifaces/default/fw/options}}, потом из {{path|/etc/net/ifaces/default/fw/iptables/filter/INPUT}}).<br />
** Если {{term|ACCEPT}} — все интерфейсы считаются внутренними<br />
** Если {{term|DROP}} — дополнительно определяем внутренние интерфейсы по строчкам {{term|-i <имя> -j ACCEPT}}<br />
* определяем дополнительно открытые сервисы (группы портов) и отдельные порты — по строчкам вида '{{term|-p <протокол> --dport <порт> -j ACCEPT}}' (это уже есть в существующем модуле)<br />
<br />
=== Модуль перезаписывает состояние ===<br />
* происходит сброс конфигурационных файлов в начальное состояние (см. выше)<br />
* в INPUT для всех внутренних интерфейсов пишется '{{term|-i <имя> -j ACCEPT}}'<br />
* в INPUT записываются строчки для всех дополнительно открытых наружу сервисов (без указания интерфейсa) '{{term|-p <протокол> --dport <порт> -j ACCEPT}}'<br />
* перезагружаем правила: {{cmd|efw restart}}<br />
<br />
=== Интерфейс ===<br />
* выбор внутренних интерфейсов<br />
* выбор открытых наружу сервисов<br />
* ввод открытых наружу дополнительных портов<br />
<br />
=== Кроме того ===<br />
* service iptables не существует, все работает через etcnet + efw.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8802Alterator/AlteratorNetIptables2009-01-30T12:08:37Z<p>VladislavZavjalov: /* Модуль перезаписывает состояние */</p>
<hr />
<div>== alterator-net-iptables ==<br />
<br />
'''Проект, по результатам разговора с vitty@'''<br />
<br />
=== Процедура сброса состояния системы (в частности, при инсталяции)===<br />
* из /etc/net/ifaces/default/fw/iptables/filter/{INPUT/OUTPUT} стираются строчки, соделжащие '-P' '-j DROP', '-j ACCEPT' (строчка ULOGD при этом сохраняется, интересно, нужно ли тут сохранять какие-то еще чужие строчки?)<br />
* в /etc/net/ifaces/default/fw/iptables/filter/INPUT дописывается:<br />
-P DROP<br />
-i lo -j ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
что-то еще, кажется надо было открыть<br />
* в /etc/net/ifaces/default/fw/iptables/filter/OUTPUT:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
* в /etc/net/ifaces/default/fw/options перезаписываются параметры:<br />
FW_TYPE="iptables"<br />
IPTABLES_HUMAN_SYNTAX=no<br />
* в /etc/net/ifaces/default/options:<br />
CONFIG_FW=yes<br />
* таким образом все интерфейсы считаются внешними, firewall включен<br />
<br />
=== Модуль определяет текущее состояние ===<br />
* определяется default policy (сперва из /etc/net/ifaces/default/fw/options, потом из /etc/net/ifaces/default/fw/iptables/filter/INPUT). <br />
** Если ACCEPT - все интерфейсы считаются внутренними<br />
** Если DROP - дополнительно определяем внутренние интерфейсы по строчкам -i <имя> -j ACCEPT<br />
* определяем дополнительно открытые сервисы (группы портов) и отдельные порты - по строчкам вида '-p <протокол> --dport <порт> -j ACCEPT' (это уже есть в существующем модуле)<br />
<br />
=== Модуль перезаписывает состояние ===<br />
* происходит сброс конфигурационных файлов в начальное состояние (см. выше)<br />
* в INPUT для всех внутренних интерфейсов пишется '-i <имя> -j ACCEPT'<br />
* в INPUT записываются строчки для всех дополнительно открытых наружу сервисов (без указания интерфейсa) '-p <протокол> --dport <порт> -j ACCEPT'<br />
* перезагружаем правила: 'efw restart'<br />
<br />
=== Интерфейс ===<br />
* выбор внутренних интерфейсов<br />
* выбор открытых наружу сервисов<br />
* ввод открытых наружу дополнительных портов<br />
[[category:sisyphus]]<br />
<br />
=== Кроме того ===<br />
* service iptables не существует, все работает через etcnet + efw.</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8801Alterator/AlteratorNetIptables2009-01-30T11:57:42Z<p>VladislavZavjalov: /* alterator-net-iptables */</p>
<hr />
<div>== alterator-net-iptables ==<br />
<br />
'''Проект, по результатам разговора с vitty@'''<br />
<br />
=== Процедура сброса состояния системы (в частности, при инсталяции)===<br />
* из /etc/net/ifaces/default/fw/iptables/filter/{INPUT/OUTPUT} стираются строчки, соделжащие '-P' '-j DROP', '-j ACCEPT' (строчка ULOGD при этом сохраняется, интересно, нужно ли тут сохранять какие-то еще чужие строчки?)<br />
* в /etc/net/ifaces/default/fw/iptables/filter/INPUT дописывается:<br />
-P DROP<br />
-i lo -j ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
что-то еще, кажется надо было открыть<br />
* в /etc/net/ifaces/default/fw/iptables/filter/OUTPUT:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
* в /etc/net/ifaces/default/fw/options перезаписываются параметры:<br />
FW_TYPE="iptables"<br />
IPTABLES_HUMAN_SYNTAX=no<br />
* в /etc/net/ifaces/default/options:<br />
CONFIG_FW=yes<br />
* таким образом все интерфейсы считаются внешними, firewall включен<br />
<br />
=== Модуль определяет текущее состояние ===<br />
* определяется default policy (сперва из /etc/net/ifaces/default/fw/options, потом из /etc/net/ifaces/default/fw/iptables/filter/INPUT). <br />
** Если ACCEPT - все интерфейсы считаются внутренними<br />
** Если DROP - дополнительно определяем внутренние интерфейсы по строчкам -i <имя> -j ACCEPT<br />
* определяем дополнительно открытые сервисы (группы портов) и отдельные порты - по строчкам вида '-p <протокол> --dport <порт> -j ACCEPT' (это уже есть в существующем модуле)<br />
<br />
=== Модуль перезаписывает состояние ===<br />
* происходит сброс конфигурационных файлов в начальное состояние (см. выше)<br />
* для всех внутренних интерфейсов пишется '-i <имя> -j ACCEPT'<br />
* записываются строчки для всех дополнительно открытых наружу сервисов (без указания интерфейсов) '-p <протокол> --dport <порт> -j ACCEPT'<br />
* перезагружаем правила: 'efw restart'<br />
<br />
=== Интерфейс ===<br />
* выбор внутренних интерфейсов<br />
* выбор открытых наружу сервисов<br />
* ввод открытых наружу дополнительных портов<br />
[[category:sisyphus]]<br />
<br />
=== Кроме того ===<br />
* service iptables не существует, все работает через etcnet + efw.</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8800Alterator/AlteratorNetIptables2009-01-30T11:57:07Z<p>VladislavZavjalov: /* alterator-net-iptables */</p>
<hr />
<div>== alterator-net-iptables ==<br />
<br />
'''Проект, по результатам разговора с vitty@'''<br />
<br />
Процедура сброса состояния системы (в частности, при инсталяции):<br />
* из /etc/net/ifaces/default/fw/iptables/filter/{INPUT/OUTPUT} стираются строчки, соделжащие '-P' '-j DROP', '-j ACCEPT' (строчка ULOGD при этом сохраняется, интересно, нужно ли тут сохранять какие-то еще чужие строчки?)<br />
* в /etc/net/ifaces/default/fw/iptables/filter/INPUT дописывается:<br />
-P DROP<br />
-i lo -j ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
что-то еще, кажется надо было открыть<br />
* в /etc/net/ifaces/default/fw/iptables/filter/OUTPUT:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
* в /etc/net/ifaces/default/fw/options перезаписываются параметры:<br />
FW_TYPE="iptables"<br />
IPTABLES_HUMAN_SYNTAX=no<br />
* в /etc/net/ifaces/default/options:<br />
CONFIG_FW=yes<br />
* таким образом все интерфейсы считаются внешними, firewall включен<br />
<br />
Модуль определяет текущее состояние:<br />
* определяется default policy (сперва из /etc/net/ifaces/default/fw/options, потом из /etc/net/ifaces/default/fw/iptables/filter/INPUT). <br />
** Если ACCEPT - все интерфейсы считаются внутренними<br />
** Если DROP - дополнительно определяем внутренние интерфейсы по строчкам -i <имя> -j ACCEPT<br />
* определяем дополнительно открытые сервисы (группы портов) и отдельные порты - по строчкам вида '-p <протокол> --dport <порт> -j ACCEPT' (это уже есть в существующем модуле)<br />
<br />
Модуль перезаписывает состояние:<br />
* происходит сброс конфигурационных файлов в начальное состояние (см. выше)<br />
* для всех внутренних интерфейсов пишется '-i <имя> -j ACCEPT'<br />
* записываются строчки для всех дополнительно открытых наружу сервисов (без указания интерфейсов) '-p <протокол> --dport <порт> -j ACCEPT'<br />
* перезагружаем правила: 'efw restart'<br />
<br />
Интерфейс:<br />
* выбор внутренних интерфейсов<br />
* выбор открытых наружу сервисов<br />
* ввод открытых наружу дополнительных портов<br />
[[category:sisyphus]]<br />
<br />
Кроме того:<br />
* service iptables не существует, все работает через etcnet + efw.</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8799Alterator/AlteratorNetIptables2009-01-30T11:48:55Z<p>VladislavZavjalov: /* alterator-net-iptables */</p>
<hr />
<div>== alterator-net-iptables ==<br />
<br />
'''Проект, по результатам разговора с vitty@'''<br />
<br />
Состояние системы по умолчанию (заботится инсталятор):<br />
* service iptables не существует, все работает через etcnet.<br />
* все интерфейсы считаются внешними, изначально закрытыми, firewall включен<br />
* в /etc/net/ifaces/default/fw/iptables/filter/INPUT записано:<br />
-P DROP<br />
-i lo -j ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
что-то еще, кажется надо было открыть<br />
* в /etc/net/ifaces/default/fw/iptables/filter/OUTPUT:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
* в /etc/net/ifaces/default/fw/options написано:<br />
FW_TYPE="iptables"<br />
IPTABLES_HUMAN_SYNTAX=no<br />
* в /etc/net/ifaces/default/options:<br />
CONFIG_FW=yes<br />
<br />
Модуль определяет текущее состояние:<br />
* определяется default policy (сперва из /etc/net/ifaces/default/fw/options, потом из /etc/net/ifaces/default/fw/iptables/filter/INPUT). <br />
** Если ACCEPT - все интерфейсы считаются внутренними<br />
** Если DROP - дополнительно определяем внутренние интерфейсы по строчкам -i <имя> -j ACCEPT<br />
* определяем дополнительно открытые сервисы (группы портов) и отдельные порты - по строчкам вида '-p <протокол> --dport <порт> -j ACCEPT' (это уже есть в существующем модуле)<br />
<br />
Модуль перезаписывает состояние:<br />
* из /etc/net/ifaces/default/fw/iptables/filter/{INPUT/OUTPUT} стираются строчки, соделжащие '-P' '-j DROP', '-j ACCEPT' (строчка ULOGD при этом сохраняется, интересно, нужно ли тут сохранять какие-то еще чужие строчки?)<br />
* туда же дописываются значения по умолчанию (указанные выше)<br />
* перезаписываются значения по умолчанию в /etc/net/ifaces/default/fw/options и /etc/net/ifaces/default/options -- все это надо делать одним скриптом<br />
* для всех внутренних интерфейсов пишется '-i <имя> -j ACCEPT'<br />
* записываются строчки для всех дополнительно открытых наружу сервисов (без указания интерфейсов) '-p <протокол> --dport <порт> -j ACCEPT'<br />
<br />
Интерфейс:<br />
* выбор внутренних интерфейсов<br />
* выбор открытых наружу сервисов<br />
* ввод открытых наружу дополнительных портов<br />
[[category:sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8798Alterator/AlteratorNetIptables2009-01-30T11:47:23Z<p>VladislavZavjalov: /* alterator-net-iptables */</p>
<hr />
<div>== alterator-net-iptables ==<br />
<br />
'''Проект, по результатам разговора с vitty@'''<br />
<br />
Состояние системы по умолчанию (заботится инсталятор):<br />
* service iptables не существует, все работает через etcnet.<br />
* все интерфейсы считаются внешними, изначально закрытыми, firewall включен<br />
* в /etc/net/ifaces/default/fw/iptables/filter/INPUT записано:<br />
-P DROP<br />
-i lo -j ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
что-то еще, кажется надо было открыть<br />
* в /etc/net/ifaces/default/fw/iptables/filter/OUTPUT:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
* в /etc/net/ifaces/default/fw/options написано:<br />
FW_TYPE="iptables"<br />
IPTABLES_HUMAN_SYNTAX=no<br />
* в /etc/net/ifaces/default/options:<br />
CONFIG_FW=yes<br />
<br />
Модуль определяет текущее состояние:<br />
* определяется default policy (сперва из /etc/net/ifaces/default/fw/options, потом из /etc/net/ifaces/default/fw/iptables/filter/INPUT). <br />
** Если ACCEPT - все интерфейсы считаются внутренними<br />
** Если DROP - дополнительно определяем внутренние интерфейсы по строчкам -i <имя> -j ACCEPT<br />
* определяем дополнительно открытые сервисы (группы портов) и отдельные порты - по строчкам вида '-p <протокол> --dport <порт> -j ACCEPT' (это уже есть в существующем модуле)<br />
<br />
Модуль перезаписывает состояние:<br />
* из /etc/net/ifaces/default/fw/iptables/filter/{INPUT/OUTPUT} стираются строчки, соделжащие '-P' '-j DROP', '-j ACCEPT' (строчка ULOGD при этом сохраняется, интересно, нужно ли тут сохранять какие-то еще чужие строчки?)<br />
* туда же дописываются значения по умолчанию (указанные выше)<br />
* перезаписываются значения по умолчанию в /etc/net/ifaces/default/fw/options и /etc/net/ifaces/default/options -- все это надо делать одним скриптом<br />
* для всех внутренних интерфейсов пишется '-i <имя> -j ACCEPT'<br />
* записываются строчки для всех дополнительно открытых сервисов, для внешних интерфейсов (без указания интерфейсов) '-p <протокол> --dport <порт> -j ACCEPT'<br />
<br />
Интерфейс:<br />
* выбор внутренних интерфейсов<br />
* выбор открытых наружу сервисов<br />
* ввод открытых наружу дополнительных портов<br />
[[category:sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8797Alterator/AlteratorNetIptables2009-01-30T11:46:46Z<p>VladislavZavjalov: /* alterator-net-iptables */</p>
<hr />
<div>== alterator-net-iptables ==<br />
<br />
'''Проект, по результатам разговора с vitty@'''<br />
<br />
Состояние системы по умолчанию (заботится инсталятор):<br />
* service iptables не существует, все работает через etcnet.<br />
* все интерфейсы считаются внешними, изначально закрытыми, firewall включен<br />
* в /etc/net/ifaces/default/fw/iptables/filter/INPUT записано:<br />
-P DROP<br />
-i lo -j ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
что-то еще, кажется надо было открыть<br />
* в /etc/net/ifaces/default/fw/iptables/filter/OUTPUT:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
* в /etc/net/ifaces/default/fw/options написано:<br />
FW_TYPE="iptables"<br />
IPTABLES_HUMAN_SYNTAX=no<br />
* в /etc/net/ifaces/default/options:<br />
CONFIG_FW=yes<br />
<br />
Модуль определяет текущее состояние:<br />
* определяется default policy (сперва из /etc/net/ifaces/default/fw/options, потом из /etc/net/ifaces/default/fw/iptables/filter/INPUT). <br />
** Если ACCEPT - все интерфейсы считаются внутренними<br />
** Если DROP - дополнительно определяем внутренние интерфейсы по строчкам -i <имя> -j ACCEPT<br />
* определяем дополнительно открытые сервисы (группы портов) и отдельные порты - по строчкам вида '-p <протокол> --dport <порт> -j ACCEPT'<br />
<br />
Модуль перезаписывает состояние:<br />
* из /etc/net/ifaces/default/fw/iptables/filter/{INPUT/OUTPUT} стираются строчки, соделжащие '-P' '-j DROP', '-j ACCEPT' (строчка ULOGD при этом сохраняется, интересно, нужно ли тут сохранять какие-то еще чужие строчки?)<br />
* туда же дописываются значения по умолчанию (указанные выше)<br />
* перезаписываются значения по умолчанию в /etc/net/ifaces/default/fw/options и /etc/net/ifaces/default/options -- все это надо делать одним скриптом<br />
* для всех внутренних интерфейсов пишется '-i <имя> -j ACCEPT'<br />
* записываются строчки для всех дополнительно открытых сервисов, для внешних интерфейсов (без указания интерфейсов) '-p <протокол> --dport <порт> -j ACCEPT'<br />
<br />
Интерфейс:<br />
* выбор внутренних интерфейсов<br />
* выбор открытых наружу сервисов<br />
* ввод открытых наружу дополнительных портов<br />
[[category:sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8796Alterator/AlteratorNetIptables2009-01-30T11:46:02Z<p>VladislavZavjalov: /* alterator-net-iptables */</p>
<hr />
<div>== alterator-net-iptables ==<br />
<br />
'''Проект, по результатам разговора с vitty@'''<br />
<br />
Состояние системы по умолчанию (заботится инсталятор):<br />
* service iptables не существует, все работает через etcnet.<br />
* все интерфейсы считаются внешними, изначально закрытыми, firewall включен<br />
* в /etc/net/ifaces/default/fw/iptables/filter/INPUT записано:<br />
-P DROP<br />
-i lo -j ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT<br />
что-то еще, кажется надо было открыть<br />
* в /etc/net/ifaces/default/fw/iptables/filter/OUTPUT:<br />
-P ACCEPT<br />
-f -j DROP<br />
-m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
* в /etc/net/ifaces/default/fw/options написано:<br />
FW_TYPE="iptables"<br />
IPTABLES_HUMAN_SYNTAX=no<br />
* в /etc/net/ifaces/default/options:<br />
CONFIG_FW=yes<br />
<br />
Модуль определяет текущее состояние:<br />
* определяется default policy (сперва из /etc/net/ifaces/default/fw/options, потом из /etc/net/ifaces/default/fw/iptables/filter/INPUT). <br />
** Если ACCEPT - значит все интерфейсы - внутренние<br />
** Если DROP - дополнительно определяем внутренние интерфейсы по строчкам -i <имя> -j ACCEPT<br />
* определяем дополнительно открытые сервисы (группы портов) и отдельные порты - по строчкам вида '-p <протокол> --dport <порт> -j ACCEPT'<br />
<br />
Модуль перезаписывает состояние:<br />
* из /etc/net/ifaces/default/fw/iptables/filter/{INPUT/OUTPUT} стираются строчки, соделжащие '-P' '-j DROP', '-j ACCEPT' (строчка ULOGD при этом сохраняется, интересно, нужно ли тут сохранять какие-то еще чужие строчки?)<br />
* туда же дописываются значения по умолчанию (указанные выше)<br />
* перезаписываются значения по умолчанию в /etc/net/ifaces/default/fw/options и /etc/net/ifaces/default/options -- все это надо делать одним скриптом<br />
* для всех внутренних интерфейсов пишется '-i <имя> -j ACCEPT'<br />
* записываются строчки для всех дополнительно открытых сервисов, для внешних интерфейсов (без указания интерфейсов) '-p <протокол> --dport <порт> -j ACCEPT'<br />
<br />
Интерфейс:<br />
* выбор внутренних интерфейсов<br />
* выбор открытых наружу сервисов<br />
* ввод открытых наружу дополнительных портов<br />
[[category:sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/AlteratorNetIptables&diff=8795Alterator/AlteratorNetIptables2009-01-30T11:45:20Z<p>VladislavZavjalov: Новая: == alterator-net-iptables == '''Проект, по результатам разговора с vitty@''' Состояние системы по умолчанию (заботится ...</p>
<hr />
<div>== alterator-net-iptables ==<br />
<br />
'''Проект, по результатам разговора с vitty@'''<br />
<br />
Состояние системы по умолчанию (заботится инсталятор):<br />
* service iptables не существует, все работает через etcnet.<br />
* все интерфейсы считаются внешними, изначально закрытыми, firewall включен<br />
* в /etc/net/ifaces/default/fw/iptables/filter/INPUT записано:<br />
* -P DROP<br />
* -i lo -j ACCEPT<br />
* -f -j DROP<br />
* -m state --state ESTABLISHED,RELATED -j ACCEPT<br />
* что-то еще, кажется надо было открыть<br />
* в /etc/net/ifaces/default/fw/iptables/filter/OUTPUT:<br />
* -P ACCEPT<br />
* -f -j DROP<br />
* -m state --state ESTABLISHED,RELATED -j ACCEPT (или такого тут не надо?)<br />
* в /etc/net/ifaces/default/fw/options написано:<br />
* FW_TYPE="iptables"<br />
* IPTABLES_HUMAN_SYNTAX=no<br />
* в /etc/net/ifaces/default/options:<br />
* CONFIG_FW=yes<br />
<br />
Модуль определяет текущее состояние:<br />
* определяется default policy (сперва из /etc/net/ifaces/default/fw/options, потом из /etc/net/ifaces/default/fw/iptables/filter/INPUT). <br />
* Если ACCEPT - значит все интерфейсы - внутренние<br />
* Если DROP - дополнительно определяем внутренние интерфейсы по строчкам -i <имя> -j ACCEPT<br />
* определяем дополнительно открытые сервисы (группы портов) и отдельные порты - по строчкам вида '-p <протокол> --dport <порт> -j ACCEPT'<br />
<br />
Модуль перезаписывает состояние:<br />
* из /etc/net/ifaces/default/fw/iptables/filter/{INPUT/OUTPUT} стираются строчки, соделжащие '-P' '-j DROP', '-j ACCEPT' (строчка ULOGD при этом сохраняется, интересно, нужно ли тут сохранять какие-то еще чужие строчки?)<br />
* туда же дописываются значения по умолчанию (указанные выше)<br />
* перезаписываются значения по умолчанию в /etc/net/ifaces/default/fw/options и /etc/net/ifaces/default/options -- все это надо делать одним скриптом<br />
* для всех внутренних интерфейсов пишется '-i <имя> -j ACCEPT'<br />
* записываются строчки для всех дополнительно открытых сервисов, для внешних интерфейсов (без указания интерфейсов) '-p <протокол> --dport <порт> -j ACCEPT'<br />
<br />
Интерфейс:<br />
* выбор внутренних интерфейсов<br />
* выбор открытых наружу сервисов<br />
* ввод открытых наружу дополнительных портов<br />
[[category:sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator&diff=8793Alterator2009-01-30T10:09:52Z<p>VladislavZavjalov: /* Разное */</p>
<hr />
<div>[[Category:Sisyphus]]<br />
[[en:Alterator]]<br />
'''Alterator''' — новое поколение платформ для разработки сложных систем. Используются по большей части [[Scheme]], C и старый добрый sh+awk. На данный момент используется как [[Installer|инсталлятор]] и конфигуратор системы. Копия части этой документации содержится в пакете [http://sisyphus.ru/srpm/alterator alterator]. <br />
<br />
Посмотреть основную часть ядра и модулей можно в [http://git.altlinux.org/people/inger/packages/ inger's git], также причастны {{man|bga}}, {{man|mike}}, {{man|sbolshakov}} и {{man|slazav}}.<br />
<br />
Для обсуждения вопросов, связанных с alterator, существует список рассылки {{lists|devel-conf}}.<br />
<br />
=== Обращение к системным администраторам ===<br />
Наверняка в alterator недостаточно модулей для решения ваших задач. Каждый модуль состоит из бэкенда и интерфейса. Разработка интерфейса — это работа для программиста, но создать бэкенд вы вполне сможете. Бэкенд пишется на произвольном языке программирования по достаточно простым правилам. Имея бэкенд, при помощи интерфейса командной строки вы уже сразу же сможете использовать наработки в своих скриптах. Хороший бэкенд — это фиксация знаний и возможность повторного использования ваших наработок другими администраторами.<br />
Напишите в список рассылки — мы поможем сделать интерфейс.<br />
<br />
===Документация===<br />
*[[Alterator/faq|Часто задаваемые вопросы]]<br />
*[[Alterator/module|Разработка модулей]] <br />
*[[Alterator/debug|Отладка модулей]]<br />
*[[Alterator/modulelist|Список модулей]]<br />
*[[Alterator/todo|Книга жалоб и предложений]]<br />
*[[Alterator/releases|Выпуски]]<br />
<br />
===Справочная информация===<br />
*[[Alterator/libraries|Стандартные библиотеки scheme, предоставляемые alterator]]<br />
*[[Alterator/stdtemplates|Стандартные интерфейсные шаблоны web-интерфейса]]<br />
<br />
'''Бэкенды:'''<br />
*[[Alterator/reserved|Зарезервированные имена]]<br />
*[[Alterator/backend2|Нативные бэкенды]]<br />
*[[Alterator/mvcbackend|Рекомендации по созданию бэкендов]]<br />
*[[Alterator/woo|Функции для работы с woo-командами]]<br />
*[[Alterator/shell|API бэкендов на shell]]<br />
*[[Alterator/perl|API бэкендов на perl]]<br />
<br />
'''Lookout:'''<br />
*[[Alterator/evolution|Описание общей структуры документа lookout]]<br />
*[[Alterator/widgets|Краткий справочник по виджетам]]<br />
*[[Alterator/lookout/form|(alterator lookout form)]] Адресация виджетов по атрибуту name. Автоматическое заполнение диалога из бэкенда и отправка значений в бэкенд.<br />
*[[Alterator/lookout/effects|(alterator lookout effects)]] Визуальные эффекты - скрытие и засеривание полей в зависимости от значений других полей<br />
<br />
'''Fbi'''<br />
*[[Alterator/fbi/wf_form|workflow form]]<br />
*[[Alterator/fbi/wf_card_index|workflow card-index]] -- почти не развивается, м.б. заменен на form<br />
<br />
===Разное===<br />
*[[Alterator/objects|Объектная система alterator]]<br />
*[[Alterator/rfc|Протокол работы с бэкендами, черновик]]<br />
*[[Alterator/role-setup|Типичные тематические роли для альтератора]]<br />
*[http://uneex.cs.msu.su/uneex/SeminarALTerator/Conspect UNИX-конспект]<br />
<br />
'''Конкретные модули'''<br />
*[[Alterator/AlteratorServices|alterator-services]]<br />
*[[Alterator/AlteratorX11|alterator-x11]]<br />
*[[Alterator/AlteratorXinetd|alterator-xinetd]]<br />
*[[Alterator/AlteratorLilo|alterator-lilo]]<br />
*[[Alterator/AlteratorL10N|alterator-l10n]]<br />
*[[Alterator/AlteratorNetIptables|alterator-net-iptables]]<br />
<br />
<br />
'''Интересные проекты'''<br />
*[http://www.redhat.com/spacewalk/ SpaceWalk]<br />
*[http://www.openpegasus.org/ OpenPegasus]<br />
*[http://live.gnome.org/JsonGlib JsonGLIB]<br />
*[http://ex-parrot.com/~pdw/Mail-RFC822-Address.html регулярное выражение для валидации e-mail адреса]<br />
*[http://freesource.info/wiki/SergeyLebedev/EisSystem Проект единой информационной системы]<br />
<br />
'''Технические требования'''<br />
*[[Alterator/Выбор_DE|Выбор DE]]<br />
<br />
=== См. также ===<br />
* <DPL><br />
namespace =<br />
titlematch = {{PAGENAME}}/%<br />
nottitlematch = {{PAGENAME}}/%/%<br />
mode = inline<br />
inlinetext=&nbsp;&bull;&#32;<br />
</DPL><br />
<br />
<br />
{{Category navigation|title=Alterator|category=Alterator|sortkey=*}}</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/i18n&diff=8733Alterator/i18n2009-01-28T15:55:20Z<p>VladislavZavjalov: /* Desktop-файлы */</p>
<hr />
<div><onlyinclude><br />
=== Локализация ===<br />
В alterator встроена система автоматического перевода текстовых сообщений на язык пользователя. Для того чтобы её задействовать необходимо отметить эти сообщения в описании интерфейса специальным образом и указать название используемого словаря.<br />
<br />
==== Описание интерфейса ====<br />
Если адрес описания интерфейса ''/<модуль>/foo/bar'', то по умолчанию этому интерфейсу сопоставляется словарь ''alterator-<модуль>'' и соответственно имя его специально указывать не надо.<br />
<br />
Вы можете явно указать другой словарь с помощью команды po-domain. Кроме того другой словарь можно задавать явно для каждого сообщения. <br />
<br />
Пример для qt:<br />
<source lang="scheme">...<br />
(po-domain "основной словарь")<br />
...<br />
(label text (_ "текст"))<br />
(label text (_ "текст" "дополнительный словарь"))<br />
...<br />
</source><br />
Инструкцией <tt>po-domain</tt> можно задать основной словарь, если он не должно вычисляться автоматически из адреса модуля.<br />
Функция <tt>_</tt> используется для получения перевода, принимает необязательный второй параметр, указывающий словарь.<br />
<br />
Пример для html:<br />
<source lang="html4strict"><br />
<html po-domain="основной словарь" ... ><br />
...<br />
<span translate="_">текст</span><br />
<span translate="дополнительный словарь">текст</span><br />
...<br />
<input name="name" value="будет переведено" translate="_"/><br />
</html><br />
</source><br />
Необязательным атрибутом <tt>po-domain</tt> можно задать основной словарь, если он не должно вычисляться автоматически.<br />
<br />
Атрибут <tt>translate</tt> применяется к span и input типа reset и submit. Наличие атрибута означает, что содержимое данного span или value данного input надо перевести используя указанный словарь, "_" -- означает основной словарь. Для обратной совместимости с предыдущими модулями если у input атрибут translate отсутствует, то value всё-равно переводится и используется словарь по умолчанию.<br />
<br />
==== Бэкенды ====<br />
<br />
Команды, приходящие к бэкенду, содержат информацию о языке используемом для переводов (параметр language). Перевод сообщений в бэкендах устроен по тому же принципу что и в описаниях интерфейсов:<br />
* основной словарь указывается явно или вычисляется как "alterator-<бэкенд>".<br />
* есть функции для переводов, они или используют основной словарь или тот что указан в дополнительном параметре.<br />
<br />
===== Бэкенд на shell =====<br />
<br />
<source lang="bash"><br />
po_domain="название словаря"<br />
...<br />
write_enum_item "aaa" "`_ "для перевода используется основной словарь"`"<br />
write_enum_item "bbb" "`_ "для перевода используется дополнительный словарь" "дополнительный словарь"`"<br />
</source><br />
Переменная <tt>po_domain</tt> содержит имя основного словаря. Функция <tt>_</tt> используется для получения перевода, принимает необязательный второй параметр, указывающий словарь.<br />
Предпочтительно использовать обратные кавычки '`' вместо конструкции $() ибо последняя не подхватывается утилитой xgettext.<br />
<br />
===== Бэкенд на perl =====<br />
<br />
<source lang="perl"><br />
$TEXTDOMAIN = "название словаря"<br />
...<br />
write_string_param("aaa", _("text"));<br />
write_string_param("bbb", _("text", "дополнительный словарь"));<br />
</source><br />
<br />
==== Desktop-файлы ====<br />
<br />
Из desktop-файлов для перевода берутся поля Name и Comment...<br />
<br />
==== Единая база переводов ====<br />
<br />
Для переводов стоит пользоваться единой базой переводов '''alterator-l10n'''. Данный пакет содержит переводы для всех модулей альтераторов. Тем самым достигается единый стиль названий (например перевод «Apply» и «Reset»). Чтобы подключить модуль к единой базе необходимо выполнить следующие действия:<br />
# свяжитесь с мантейнером пакета alterator-l10n ({{man|inger}}, {{man|slazav}}, {{man|cas}}) и сообщите URL репозитория в [http://git.altlinux.org git.altlinux.org]<br />
# дождитесь когда ваш пакет будет включён в alterator-l10n<br />
# добавьте пакет alterator-l10n в сборочные зависимости модуля (тег BuildPreReq)<br />
<br />
После этого при каждой сборке пакета автоматически будут создаваться и размещаться в результирующем rpm-пакете) переводы для всех поддерживаемых языков.<br />
Если в вашем модуле уже были свои варианты переводов (каталог po), то их надо удалить вместе с pot-файлом.<br />
</onlyinclude><br />
<br />
[[Alterator/AlteratorL10N]] -- Более актуальтая информация о alterator-rl10n<br />
<br />
<br />
{{Alterator modules-nav}}</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/i18n&diff=8732Alterator/i18n2009-01-28T15:55:05Z<p>VladislavZavjalov: </p>
<hr />
<div><onlyinclude><br />
=== Локализация ===<br />
В alterator встроена система автоматического перевода текстовых сообщений на язык пользователя. Для того чтобы её задействовать необходимо отметить эти сообщения в описании интерфейса специальным образом и указать название используемого словаря.<br />
<br />
==== Описание интерфейса ====<br />
Если адрес описания интерфейса ''/<модуль>/foo/bar'', то по умолчанию этому интерфейсу сопоставляется словарь ''alterator-<модуль>'' и соответственно имя его специально указывать не надо.<br />
<br />
Вы можете явно указать другой словарь с помощью команды po-domain. Кроме того другой словарь можно задавать явно для каждого сообщения. <br />
<br />
Пример для qt:<br />
<source lang="scheme">...<br />
(po-domain "основной словарь")<br />
...<br />
(label text (_ "текст"))<br />
(label text (_ "текст" "дополнительный словарь"))<br />
...<br />
</source><br />
Инструкцией <tt>po-domain</tt> можно задать основной словарь, если он не должно вычисляться автоматически из адреса модуля.<br />
Функция <tt>_</tt> используется для получения перевода, принимает необязательный второй параметр, указывающий словарь.<br />
<br />
Пример для html:<br />
<source lang="html4strict"><br />
<html po-domain="основной словарь" ... ><br />
...<br />
<span translate="_">текст</span><br />
<span translate="дополнительный словарь">текст</span><br />
...<br />
<input name="name" value="будет переведено" translate="_"/><br />
</html><br />
</source><br />
Необязательным атрибутом <tt>po-domain</tt> можно задать основной словарь, если он не должно вычисляться автоматически.<br />
<br />
Атрибут <tt>translate</tt> применяется к span и input типа reset и submit. Наличие атрибута означает, что содержимое данного span или value данного input надо перевести используя указанный словарь, "_" -- означает основной словарь. Для обратной совместимости с предыдущими модулями если у input атрибут translate отсутствует, то value всё-равно переводится и используется словарь по умолчанию.<br />
<br />
==== Бэкенды ====<br />
<br />
Команды, приходящие к бэкенду, содержат информацию о языке используемом для переводов (параметр language). Перевод сообщений в бэкендах устроен по тому же принципу что и в описаниях интерфейсов:<br />
* основной словарь указывается явно или вычисляется как "alterator-<бэкенд>".<br />
* есть функции для переводов, они или используют основной словарь или тот что указан в дополнительном параметре.<br />
<br />
===== Бэкенд на shell =====<br />
<br />
<source lang="bash"><br />
po_domain="название словаря"<br />
...<br />
write_enum_item "aaa" "`_ "для перевода используется основной словарь"`"<br />
write_enum_item "bbb" "`_ "для перевода используется дополнительный словарь" "дополнительный словарь"`"<br />
</source><br />
Переменная <tt>po_domain</tt> содержит имя основного словаря. Функция <tt>_</tt> используется для получения перевода, принимает необязательный второй параметр, указывающий словарь.<br />
Предпочтительно использовать обратные кавычки '`' вместо конструкции $() ибо последняя не подхватывается утилитой xgettext.<br />
<br />
===== Бэкенд на perl =====<br />
<br />
<source lang="perl"><br />
$TEXTDOMAIN = "название словаря"<br />
...<br />
write_string_param("aaa", _("text"));<br />
write_string_param("bbb", _("text", "дополнительный словарь"));<br />
</source><br />
<br />
==== Desktop-файлы ====<br />
<br />
Из desktop-файлов для переворда берутся поля Name и Comment...<br />
<br />
==== Единая база переводов ====<br />
<br />
Для переводов стоит пользоваться единой базой переводов '''alterator-l10n'''. Данный пакет содержит переводы для всех модулей альтераторов. Тем самым достигается единый стиль названий (например перевод «Apply» и «Reset»). Чтобы подключить модуль к единой базе необходимо выполнить следующие действия:<br />
# свяжитесь с мантейнером пакета alterator-l10n ({{man|inger}}, {{man|slazav}}, {{man|cas}}) и сообщите URL репозитория в [http://git.altlinux.org git.altlinux.org]<br />
# дождитесь когда ваш пакет будет включён в alterator-l10n<br />
# добавьте пакет alterator-l10n в сборочные зависимости модуля (тег BuildPreReq)<br />
<br />
После этого при каждой сборке пакета автоматически будут создаваться и размещаться в результирующем rpm-пакете) переводы для всех поддерживаемых языков.<br />
Если в вашем модуле уже были свои варианты переводов (каталог po), то их надо удалить вместе с pot-файлом.<br />
</onlyinclude><br />
<br />
[[Alterator/AlteratorL10N]] -- Более актуальтая информация о alterator-rl10n<br />
<br />
<br />
{{Alterator modules-nav}}</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/i18n&diff=8731Alterator/i18n2009-01-28T15:54:38Z<p>VladislavZavjalov: /* Локализация */</p>
<hr />
<div><onlyinclude><br />
=== Локализация ===<br />
В alterator встроена система автоматического перевода текстовых сообщений на язык пользователя. Для того чтобы её задействовать необходимо отметить эти сообщения в описании интерфейса специальным образом и указать название используемого словаря.<br />
<br />
==== Описание интерфейса ====<br />
Если адрес описания интерфейса ''/<модуль>/foo/bar'', то по умолчанию этому интерфейсу сопоставляется словарь ''alterator-<модуль>'' и соответственно имя его специально указывать не надо.<br />
<br />
Вы можете явно указать другой словарь с помощью команды po-domain. Кроме того другой словарь можно задавать явно для каждого сообщения. <br />
<br />
Пример для qt:<br />
<source lang="scheme">...<br />
(po-domain "основной словарь")<br />
...<br />
(label text (_ "текст"))<br />
(label text (_ "текст" "дополнительный словарь"))<br />
...<br />
</source><br />
Инструкцией <tt>po-domain</tt> можно задать основной словарь, если он не должно вычисляться автоматически из адреса модуля.<br />
Функция <tt>_</tt> используется для получения перевода, принимает необязательный второй параметр, указывающий словарь.<br />
<br />
Пример для html:<br />
<source lang="html4strict"><br />
<html po-domain="основной словарь" ... ><br />
...<br />
<span translate="_">текст</span><br />
<span translate="дополнительный словарь">текст</span><br />
...<br />
<input name="name" value="будет переведено" translate="_"/><br />
</html><br />
</source><br />
Необязательным атрибутом <tt>po-domain</tt> можно задать основной словарь, если он не должно вычисляться автоматически.<br />
<br />
Атрибут <tt>translate</tt> применяется к span и input типа reset и submit. Наличие атрибута означает, что содержимое данного span или value данного input надо перевести используя указанный словарь, "_" -- означает основной словарь. Для обратной совместимости с предыдущими модулями если у input атрибут translate отсутствует, то value всё-равно переводится и используется словарь по умолчанию.<br />
<br />
==== Бэкенды ====<br />
<br />
Команды, приходящие к бэкенду, содержат информацию о языке используемом для переводов (параметр language). Перевод сообщений в бэкендах устроен по тому же принципу что и в описаниях интерфейсов:<br />
* основной словарь указывается явно или вычисляется как "alterator-<бэкенд>".<br />
* есть функции для переводов, они или используют основной словарь или тот что указан в дополнительном параметре.<br />
<br />
===== Бэкенд на shell =====<br />
<br />
<source lang="bash"><br />
po_domain="название словаря"<br />
...<br />
write_enum_item "aaa" "`_ "для перевода используется основной словарь"`"<br />
write_enum_item "bbb" "`_ "для перевода используется дополнительный словарь" "дополнительный словарь"`"<br />
</source><br />
Переменная <tt>po_domain</tt> содержит имя основного словаря. Функция <tt>_</tt> используется для получения перевода, принимает необязательный второй параметр, указывающий словарь.<br />
Предпочтительно использовать обратные кавычки '`' вместо конструкции $() ибо последняя не подхватывается утилитой xgettext.<br />
<br />
===== Бэкенд на perl =====<br />
<br />
<source lang="perl"><br />
$TEXTDOMAIN = "название словаря"<br />
...<br />
write_string_param("aaa", _("text"));<br />
write_string_param("bbb", _("text", "дополнительный словарь"));<br />
</source><br />
<br />
==== Desktop-файлы ===<br />
<br />
Из desktop-файлов для переворда берутся поля Name и Comment...<br />
<br />
==== Единая база переводов ====<br />
<br />
Для переводов стоит пользоваться единой базой переводов '''alterator-l10n'''. Данный пакет содержит переводы для всех модулей альтераторов. Тем самым достигается единый стиль названий (например перевод «Apply» и «Reset»). Чтобы подключить модуль к единой базе необходимо выполнить следующие действия:<br />
# свяжитесь с мантейнером пакета alterator-l10n ({{man|inger}}, {{man|slazav}}, {{man|cas}}) и сообщите URL репозитория в [http://git.altlinux.org git.altlinux.org]<br />
# дождитесь когда ваш пакет будет включён в alterator-l10n<br />
# добавьте пакет alterator-l10n в сборочные зависимости модуля (тег BuildPreReq)<br />
<br />
После этого при каждой сборке пакета автоматически будут создаваться и размещаться в результирующем rpm-пакете) переводы для всех поддерживаемых языков.<br />
Если в вашем модуле уже были свои варианты переводов (каталог po), то их надо удалить вместе с pot-файлом.<br />
</onlyinclude><br />
<br />
[[Alterator/AlteratorL10N]] -- Более актуальтая информация о alterator-rl10n<br />
<br />
<br />
{{Alterator modules-nav}}</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/i18n&diff=8730Alterator/i18n2009-01-28T15:53:03Z<p>VladislavZavjalov: /* Единая база переводов */</p>
<hr />
<div><onlyinclude><br />
=== Локализация ===<br />
В alterator встроена система автоматического перевода текстовых сообщений на язык пользователя. Для того чтобы её задействовать необходимо отметить эти сообщения в описании интерфейса специальным образом и указать название используемого словаря.<br />
<br />
==== Описание интерфейса ====<br />
Если адрес описания интерфейса ''/<модуль>/foo/bar'', то по умолчанию этому интерфейсу сопоставляется словарь ''alterator-<модуль>'' и соответственно имя его специально указывать не надо.<br />
<br />
Вы можете явно указать другой словарь с помощью команды po-domain. Кроме того другой словарь можно задавать явно для каждого сообщения. <br />
<br />
Пример для qt:<br />
<source lang="scheme">...<br />
(po-domain "основной словарь")<br />
...<br />
(label text (_ "текст"))<br />
(label text (_ "текст" "дополнительный словарь"))<br />
...<br />
</source><br />
Инструкцией <tt>po-domain</tt> можно задать основной словарь, если он не должно вычисляться автоматически из адреса модуля.<br />
Функция <tt>_</tt> используется для получения перевода, принимает необязательный второй параметр, указывающий словарь.<br />
<br />
Пример для html:<br />
<source lang="html4strict"><br />
<html po-domain="основной словарь" ... ><br />
...<br />
<span translate="_">текст</span><br />
<span translate="дополнительный словарь">текст</span><br />
...<br />
<input name="name" value="будет переведено" translate="_"/><br />
</html><br />
</source><br />
Необязательным атрибутом <tt>po-domain</tt> можно задать основной словарь, если он не должно вычисляться автоматически.<br />
<br />
Атрибут <tt>translate</tt> применяется к span и input типа reset и submit. Наличие атрибута означает, что содержимое данного span или value данного input надо перевести используя указанный словарь, "_" -- означает основной словарь. Для обратной совместимости с предыдущими модулями если у input атрибут translate отсутствует, то value всё-равно переводится и используется словарь по умолчанию.<br />
<br />
==== Бэкенды ====<br />
<br />
Команды, приходящие к бэкенду, содержат информацию о языке используемом для переводов (параметр language). Перевод сообщений в бэкендах устроен по тому же принципу что и в описаниях интерфейсов:<br />
* основной словарь указывается явно или вычисляется как "alterator-<бэкенд>".<br />
* есть функции для переводов, они или используют основной словарь или тот что указан в дополнительном параметре.<br />
<br />
===== Бэкенд на shell =====<br />
<br />
<source lang="bash"><br />
po_domain="название словаря"<br />
...<br />
write_enum_item "aaa" "`_ "для перевода используется основной словарь"`"<br />
write_enum_item "bbb" "`_ "для перевода используется дополнительный словарь" "дополнительный словарь"`"<br />
</source><br />
Переменная <tt>po_domain</tt> содержит имя основного словаря. Функция <tt>_</tt> используется для получения перевода, принимает необязательный второй параметр, указывающий словарь.<br />
Предпочтительно использовать обратные кавычки '`' вместо конструкции $() ибо последняя не подхватывается утилитой xgettext.<br />
<br />
===== Бэкенд на perl =====<br />
<br />
<source lang="perl"><br />
$TEXTDOMAIN = "название словаря"<br />
...<br />
write_string_param("aaa", _("text"));<br />
write_string_param("bbb", _("text", "дополнительный словарь"));<br />
</source><br />
<br />
==== Единая база переводов ====<br />
<br />
Для переводов стоит пользоваться единой базой переводов '''alterator-l10n'''. Данный пакет содержит переводы для всех модулей альтераторов. Тем самым достигается единый стиль названий (например перевод «Apply» и «Reset»). Чтобы подключить модуль к единой базе необходимо выполнить следующие действия:<br />
# свяжитесь с мантейнером пакета alterator-l10n ({{man|inger}}, {{man|slazav}}, {{man|cas}}) и сообщите URL репозитория в [http://git.altlinux.org git.altlinux.org]<br />
# дождитесь когда ваш пакет будет включён в alterator-l10n<br />
# добавьте пакет alterator-l10n в сборочные зависимости модуля (тег BuildPreReq)<br />
<br />
После этого при каждой сборке пакета автоматически будут создаваться и размещаться в результирующем rpm-пакете) переводы для всех поддерживаемых языков.<br />
Если в вашем модуле уже были свои варианты переводов (каталог po), то их надо удалить вместе с pot-файлом.<br />
</onlyinclude><br />
<br />
[[Alterator/AlteratorL10N]] -- Более актуальтая информация о alterator-rl10n<br />
<br />
<br />
{{Alterator modules-nav}}</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/i18n&diff=8729Alterator/i18n2009-01-28T15:51:48Z<p>VladislavZavjalov: /* Единая база переводов */</p>
<hr />
<div><onlyinclude><br />
=== Локализация ===<br />
В alterator встроена система автоматического перевода текстовых сообщений на язык пользователя. Для того чтобы её задействовать необходимо отметить эти сообщения в описании интерфейса специальным образом и указать название используемого словаря.<br />
<br />
==== Описание интерфейса ====<br />
Если адрес описания интерфейса ''/<модуль>/foo/bar'', то по умолчанию этому интерфейсу сопоставляется словарь ''alterator-<модуль>'' и соответственно имя его специально указывать не надо.<br />
<br />
Вы можете явно указать другой словарь с помощью команды po-domain. Кроме того другой словарь можно задавать явно для каждого сообщения. <br />
<br />
Пример для qt:<br />
<source lang="scheme">...<br />
(po-domain "основной словарь")<br />
...<br />
(label text (_ "текст"))<br />
(label text (_ "текст" "дополнительный словарь"))<br />
...<br />
</source><br />
Инструкцией <tt>po-domain</tt> можно задать основной словарь, если он не должно вычисляться автоматически из адреса модуля.<br />
Функция <tt>_</tt> используется для получения перевода, принимает необязательный второй параметр, указывающий словарь.<br />
<br />
Пример для html:<br />
<source lang="html4strict"><br />
<html po-domain="основной словарь" ... ><br />
...<br />
<span translate="_">текст</span><br />
<span translate="дополнительный словарь">текст</span><br />
...<br />
<input name="name" value="будет переведено" translate="_"/><br />
</html><br />
</source><br />
Необязательным атрибутом <tt>po-domain</tt> можно задать основной словарь, если он не должно вычисляться автоматически.<br />
<br />
Атрибут <tt>translate</tt> применяется к span и input типа reset и submit. Наличие атрибута означает, что содержимое данного span или value данного input надо перевести используя указанный словарь, "_" -- означает основной словарь. Для обратной совместимости с предыдущими модулями если у input атрибут translate отсутствует, то value всё-равно переводится и используется словарь по умолчанию.<br />
<br />
==== Бэкенды ====<br />
<br />
Команды, приходящие к бэкенду, содержат информацию о языке используемом для переводов (параметр language). Перевод сообщений в бэкендах устроен по тому же принципу что и в описаниях интерфейсов:<br />
* основной словарь указывается явно или вычисляется как "alterator-<бэкенд>".<br />
* есть функции для переводов, они или используют основной словарь или тот что указан в дополнительном параметре.<br />
<br />
===== Бэкенд на shell =====<br />
<br />
<source lang="bash"><br />
po_domain="название словаря"<br />
...<br />
write_enum_item "aaa" "`_ "для перевода используется основной словарь"`"<br />
write_enum_item "bbb" "`_ "для перевода используется дополнительный словарь" "дополнительный словарь"`"<br />
</source><br />
Переменная <tt>po_domain</tt> содержит имя основного словаря. Функция <tt>_</tt> используется для получения перевода, принимает необязательный второй параметр, указывающий словарь.<br />
Предпочтительно использовать обратные кавычки '`' вместо конструкции $() ибо последняя не подхватывается утилитой xgettext.<br />
<br />
===== Бэкенд на perl =====<br />
<br />
<source lang="perl"><br />
$TEXTDOMAIN = "название словаря"<br />
...<br />
write_string_param("aaa", _("text"));<br />
write_string_param("bbb", _("text", "дополнительный словарь"));<br />
</source><br />
<br />
==== Единая база переводов ====<br />
<br />
Для переводов стоит пользоваться единой базой переводов '''alterator-l10n'''. Данный пакет содержит переводы для всех модулей альтераторов. Тем самым достигается единый стиль названий (например перевод «Apply» и «Reset»). Чтобы подключить модуль к единой базе необходимо выполнить следующие действия:<br />
# свяжитесь с мантейнером пакета alterator-l10n ({{man|inger}}, {{man|slazav}}, {{man|cas}}) и сообщите URL репозитория в [http://git.altlinux.org git.altlinux.org]<br />
# дождитесь когда ваш пакет будет включён в alterator-l10n<br />
# добавьте пакет alterator-l10n в сборочные зависимости модуля (тег BuildPreReq)<br />
<br />
После этого при каждой сборке пакета автоматически будут создаваться и размещаться в результирующем rpm-пакете) переводы для всех поддерживаемых языков.<br />
Если в вашем модуле уже были свои варианты переводов (каталог po), то их надо удалить вместе с pot-файлом.<br />
</onlyinclude><br />
<br />
[[Alterator/AlteratorL10N Более актуальтая информация о alterator-rl10n]]<br />
<br />
<br />
{{Alterator modules-nav}}</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8728Alterator/l10n2009-01-28T15:49:46Z<p>VladislavZavjalov: /* Кроме того */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== Справка ==<br />
<br />
=== Старая схема (4.1, 5.0, Sisyphus) ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема (5.0, Sisyphus) ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== Переводы ==<br />
<br />
=== Старая схема (4.1, 5.0?) ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы автоматически берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
Новая схема решает все эти проблемы.<br />
<br />
=== Новая схема (5.0?, Sisyphus) ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo, xinetd, services, samba}<br />
<br />
С точки зрения мейнтейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»).<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»).<br />
* Находясь в alterator-l10n обновляем словарь своего модуля модуля: '''./update_module <директория с модулем>''' (директория с модулем — та, в которой живет Makefile). При этом недостающие переводы берутся из общего словаря.<br />
* При первом запуске update_module (если словаря для этого модуля еще нет в alterator-l10n), словарь берется из модуля.<br />
* Правим словарь своего модуля в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы опять возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все словари модулей)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит только внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Некоторая особенность связана с переводами полей {{term|Name}} и {{term|Comment}} в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придётся каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт {{cmd|./update_desktop <директория с модулем>}} мы обновляем desktop-файлы модуля…<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь также используется для построения словарей модулей в старой схеме, это лучше делать хитрее и вручную.<br />
<br />
== Кроме того ==<br />
<br />
Модуль может паковать справку и переводы самостоятельно, не используя alterator-l10n<br />
<br />
Система локализации alterator также описана в разделе [[Alterator/module#Локализация]]<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8727Alterator/l10n2009-01-28T15:49:22Z<p>VladislavZavjalov: /* Кроме того */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== Справка ==<br />
<br />
=== Старая схема (4.1, 5.0, Sisyphus) ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема (5.0, Sisyphus) ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== Переводы ==<br />
<br />
=== Старая схема (4.1, 5.0?) ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы автоматически берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
Новая схема решает все эти проблемы.<br />
<br />
=== Новая схема (5.0?, Sisyphus) ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo, xinetd, services, samba}<br />
<br />
С точки зрения мейнтейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»).<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»).<br />
* Находясь в alterator-l10n обновляем словарь своего модуля модуля: '''./update_module <директория с модулем>''' (директория с модулем — та, в которой живет Makefile). При этом недостающие переводы берутся из общего словаря.<br />
* При первом запуске update_module (если словаря для этого модуля еще нет в alterator-l10n), словарь берется из модуля.<br />
* Правим словарь своего модуля в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы опять возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все словари модулей)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит только внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Некоторая особенность связана с переводами полей {{term|Name}} и {{term|Comment}} в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придётся каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт {{cmd|./update_desktop <директория с модулем>}} мы обновляем desktop-файлы модуля…<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь также используется для построения словарей модулей в старой схеме, это лучше делать хитрее и вручную.<br />
<br />
== Кроме того ==<br />
<br />
Модуль может паковать справку и переводы самостоятельно, не используя alterator-l10n<br />
<br />
Система локализации alterator также описана в [[Alterator/module#Локализация]]<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8726Alterator/l10n2009-01-28T15:46:13Z<p>VladislavZavjalov: </p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== Справка ==<br />
<br />
=== Старая схема (4.1, 5.0, Sisyphus) ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема (5.0, Sisyphus) ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== Переводы ==<br />
<br />
=== Старая схема (4.1, 5.0?) ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы автоматически берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
Новая схема решает все эти проблемы.<br />
<br />
=== Новая схема (5.0?, Sisyphus) ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo, xinetd, services, samba}<br />
<br />
С точки зрения мейнтейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»).<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»).<br />
* Находясь в alterator-l10n обновляем словарь своего модуля модуля: '''./update_module <директория с модулем>''' (директория с модулем — та, в которой живет Makefile). При этом недостающие переводы берутся из общего словаря.<br />
* При первом запуске update_module (если словаря для этого модуля еще нет в alterator-l10n), словарь берется из модуля.<br />
* Правим словарь своего модуля в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы опять возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все словари модулей)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит только внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Некоторая особенность связана с переводами полей {{term|Name}} и {{term|Comment}} в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придётся каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт {{cmd|./update_desktop <директория с модулем>}} мы обновляем desktop-файлы модуля…<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь также используется для построения словарей модулей в старой схеме, это лучше делать хитрее и вручную.<br />
<br />
== Кроме того ==<br />
<br />
Модуль может паковать справку и переводы самостоятельно, не используя alterator-l10n<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=%D0%A8%D0%BA%D0%BE%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80_4.1&diff=8721Школьный сервер 4.12009-01-28T15:10:06Z<p>VladislavZavjalov: /* 28.01.2009 (cas) */</p>
<hr />
<div>== Анонс ==<br />
<br />
Компания ALT Linux объявляет о выпуске серверного дистрибутива для образовательных учреждений '''ALT Linux 4.1 Школьный Сервер'''.<br />
<br />
Интерфейс Школьного Сервера позволяет легко управлять:<br />
<br />
* межсетевым экраном (с помощью упрощенного или расширенного интерфейса);<br />
* почтовым сервером с поддержкой средств борьбы с вирусами и спамом;<br />
* веб-сервером Apache2 (модули веб-сервера, виртуальные сервера);<br />
* прокси-сервером (с поддержкой вывода статистики доступа);<br />
* Samba-сервером (организация доступа к каталогам, доступным по протоколу Samba);<br />
* FTP-сервером;<br />
* обновлениями системы (включая настройку источников обновлений);<br />
* учётными записями пользователей (в том числе изменять учётные данные и квоты на используемое пространство);<br />
* сетевыми интерфейсами;<br />
* источниками бесперебойного питания;<br />
* созданием локальных зеркал репозиториев;<br />
* резервным копированием;<br />
* синхронизацией времени на сервере;<br />
* выделением IP-адресов для локальной сети (DHCP-сервер);<br />
* веб-ориентированными приложениями (Moodle и MediaWiki).<br />
<br />
Основные отличия от Office Server 4.0:<br />
<br />
* современная пакетная база<br />
* ядро Linux 2.6.25, поддерживающее более широкий спектр оборудования<br />
* новый внешний вид центра управления системой и установщика<br />
* FTP, почта и Samba берут систему пользователей из LDAP;<br />
* Новые модули центра управления системой (в том числе: резервного копирования, создания локальных зеркал репозиториев,<br />
* поддержка Moodle — системы для создания курсов и веб-сайтов, находящей все большее распространение в образовательных учреждениях<br />
* поддержка MediaWiki — системы для веб-сайтов, работающих по технологии «вики».<br />
<br />
ISO-образ CD диска и образ для флеш-носителя находятся по адресу:<br />
<br />
ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/4.1/school-server/4.1.0/iso/, а также будут доступны с ближайшего зеркала.<br />
<br />
Список действующих зеркал можно найти по адресу<br />
<br />
http://www.altlinux.ru/products/downloads/<br />
<br />
Доступны следующие образы (перед именем файла указана его контрольная сумма):<br />
<br />
<pre>9c2cf1ca56e3584323f3e62384c1c6fc altlinux-4.1.0-school_server-i586-install-cd.iso</pre><br />
<br />
Список рассылки, посвящённый дистрибутивам ALT Linux Школьный Сервер:<br />
<br />
https://lists.altlinux.org/mailman/listinfo/office-server (на русском языке)<br />
<br />
== Список существующих модулей альтератора ==<br />
<br />
{| class="standard"<br />
|-<br />
!Модуль<br />
!Комментарий<br />
!Справка<br />
|-<br />
|alterator-sysconfig<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-lilo<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-sysinfo<br />
|{{есть}} <br />
|{{есть}}<br />
|-<br />
|alterator-xinetd<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-services<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-logs<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-pkg<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-datetime<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-tzone<br />
|{{есть}} непереведенные города в некоторых странах, отличных от России...<br />
|{{есть}}<br />
|-<br />
|alterator-root<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-users<br />
|{{есть}}<br />
* {{altbug|18310|Неочевидный способ заведения пользователей}}<br />
* {{altbug|18309|Отрезает пробелы из конца пароля}}<br />
|{{есть}}<br />
|-<br />
|alterator-auth<br />
|{{есть}} <br />
|{{есть}}<br />
|-<br />
|alterator-net-eth<br />
|{{есть}} {{man|slazav}}: при смене ip, возможно, стоит делать редирект на новый ip. а еще он иногда "глючит", если менять способ получения ip со статического на DHCP (может присвоить старый ip! который был в заданный в настройках как статический! бага?) <br />
|{{есть}}<br />
|-<br />
|alterator-net-wifi<br />
|{{есть}} При нажатии на кнопку "Перенастроить интерфейс" начинает много флудить в dmesg о том, что он постоянно перенастраивает, пока не будет выполнен переход на какой-нибудь другой модуль. -- актуально не для всех wifi-карточек, видимо.<br />
|{{есть}}<br />
|-<br />
|alterator-net-pptp<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-net-ppoe<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-net-iptables<br />
|{{есть}} после создания 1 правила, подвис и перезагрузился, теперь не создает правила через альтератор, но может редактировать существующие (бага?)<br />
|{{есть}}поддерживает не все параметры? в ручную правило вписать можно(проверено на работоспособность!), а через альтератор ругается! нет параметра " --to "??? <br />
|-<br />
|alterator-vsftpd<br />
|{{есть}} <br />
|{{есть}}<br />
|-<br />
|alterator-squid<br />
|{{есть}}, В разделе настройки прокси-сервера не задаётся доступ по пользователю/паролю, {{man|amike}}<br />
|{{есть}} нет возможности задания параметра "transparent" и многих других, нет возможности ограничить пользователей по ip (всмысле работает только с под сетями)<br />
|-<br />
|alterator-samba<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-nut<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-dhcp<br />
|{{есть}}нет возможности сменить ip адрес для постоянного клиента...<br />
|{{есть}}<br />
|-<br />
|alterator-postfix-restrictions<br />
|{{есть}} Нужны RBL-сервера по умолчанию (хотя бы zen.spamhaus.org + dul.dnsbl.sorbs.net).<br />
|{{есть}} Нужно по-человечески объяснить, что "фильтрация клиентов" -- это фильтрация по IP-адресам<br />
|-<br />
|alterator-dovecot<br />
|{{есть}} <br />
|{{есть}}<br />
|-<br />
|alterator-spamassassin<br />
|{{есть}} <br />
|{{есть}}<br />
|-<br />
|alterator-ulogd<br />
|{{есть}}<br />
* Статистика "Сетевого трафика" должна иметь группировку по IP. <br />
* Не работает?! Кто-нибудь знает, как оно должно работать? ;)<br />
|{{есть}}<br />
|-<br />
|alterator-lightsquid<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-ahttpd<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-mirror<br />
|{{есть}} todo на далекое и светлое будущее: надо делать прикидку свободного места, иначе велика вероятность что пользователь когда-нибудь проснется и обнаружит забитый под завязку диск и почти нерабочую систему.<br />
|{{есть}}<br />
|-<br />
|alterator-openldap<br />
|{{есть}}<br />
|{{есть}}<br />
|-<br />
|alterator-synbak<br />
|{{есть}}<br />
* FR: Нет возможности резервного копирования на удалённый сервер<br />
* При "создании новой резервной копии" WWW-интерфейс недоступен до тех пор, пока команда полностью не отработает (на медленных дисках может длиться часами)<br />
|{{есть}} {{man|george}}: В разделе "справка" много полезной информации, но не говорится о том, как начать пользоваться модулем<br />
* [[ALT_Linux_4.1_Office_Server/SynbakActualHelp]]<br />
|}<br />
<br />
== Отсутствующие, но полезные модули альтератора ==<br />
<br />
{| class="standard"<br />
|-<br />
! Модуль || Комментарий<br />
|-<br />
| alterator-net-ppp || модифицировать до появления там интерфейса для pppd. Сейчас pppd в дистрибутиве нет. Это неправильно, надо добавлять. Было бы неплохо придумать, как объединить очень сильно пересекающиеся по коду alterator-net-{pptp,pppoe} и чуточку модифицировать под обычный ppp (было бы неплохо реанимировать wvdial и альтератор сделать вокруг него - единственный консольный дозвонщик, да и апстрим ожил. Умеет несколько соединений с разными провайдерами, его конфиг прост как двери)<br />
|}<br />
<br />
== Документация ==<br />
<br />
=== Вид, в котором она представляется пользователям ===<br />
<br />
==== install notes ====<br />
<br />
* общие слова типа «Дистрибутив успешно установлен»<br />
* редирект пользовалетей на едиую точку входа (см. ниже)<br />
<br />
==== Документация в html-версии ====<br />
<br />
Располагается тут: <tt><nowiki>http://localhost/ald-docs</nowiki></tt><br />
<br />
Что оно содержит:<br />
* На видном месте — как найти moodle и mediawiki. Люди их не находят, они не понимают, что «всё уже работает», пытаются искать это где-то в модулях. Нужно направить их в правильное русло.<br />
* На видном месте — ссылка на интерфейс cups-а. Ситуация аналогична.<br />
* На видном месте — ссылка на альтератор. Для единообразия.<br />
* Информацию из руководств (наверное, имеет смысл опустить информацию об установке системы вообще)<br />
<br />
При этом аналог печатной версии документации по НП-21 полностью опакечен.<br />
<br />
==== В концепции НП-21 ====<br />
<br />
* «Руководство пользователя» (объёмом не менее 0,5 п. л.)<br />
* «Руководство системного программиста» (объёмом не менее 0,5 п. л.)<br />
<br />
Формат печатной документации — А4.<br />
<br />
Задумывалось, что руководство системного администратора будет в целом соответствовать ГОСТ 19.505-79, а руководство пользователя РД 50-34.698-90.<br />
<br />
И хотя в требованиях конкурса это прямо не указывается, желательно придерживаться требований данных руководящих документов.<br />
<br />
== Полезно для ознакомления ==<br />
<br />
[[Releases/40/PretenziiOfficeServer]] - почему не выпустили на 4.0<br />
<br />
== Доделать ==<br />
* Исправить грабли при работе с более чем 1 интерфейсом в alterator-net-iptables {{man|slazav}}<br />
* разобраться с конфигом апача на предмет https и index.html-дефолтной-затычки {{man|mex3}}+все желающие покопаться в странных конфигах апача, у меня уже с фантазией туговато<br />
* alterator-users. Переложить в 4.1 {{man|slazav}}<br />
* alterator-chronograph - нет справки (пустая), не локализован, почему-то в списке LDAP Domain ничего нет - работоспособность сомнительна. {{man|manowar}}<br />
* alterator-openldap. Ссылка "Запустить, перезапустить...и т.п." ведёт в странное место, другие модули ходят за этим в другое. Лучше исправить, но если нет возможности и противопоказаний - можно оставить. {{man|manowar}}<br />
* <strike>64-битная версия, хотя бы в статусе беты</strike> ее не будет из-за подземного стука иксов/ядра. Конкретнее, пожалуйста, со ссылками на bugzilla. {{man|lsv}} - Барабашка, повешай, наконец, багу!<br />
<br />
=== Документация ===<br />
<br />
До сих пор не вижу:<br />
* <strike>справки для модуля "Центр управления системой"</strike><br />
* <strike>приветственного текста для главной страницы альтератора:</strike> обсуждение в docs@: ничего не добавляем<br />
* <strike>справки от модуля alterator-mirror</strike><br />
* <strike>справки для модуля alterator-office-server (шага про root, про выбор интерфейса+ldap). При этом практически готовый текст про ldap отправлялся на почту (эту или azol@altlinux.org)</strike><br />
* <strike>Нет поправки справки к модулю alterator-net-iptables с workaround-ом баги с переключением интерфейсов. (возможно, будет не актуально по результатам работы Славы)</strike> не актуально<br />
* <strike>Нет добавлений в справки модулей о необходимости запускать службу для её работы (недостаточно настройки):<strike><br />
* <strike>исправить в обычном indexhtml информацию про пароль админоюзеров в mediawiki и moodle. Теперь пользователей зовут root и пароль у них будет как у root. Кроме того, mysql теперь поднят и работает из коробки.</strike><br />
<br />
<strike>Всё, кроме последнего пункта, было передано в промежуток времени с 15.01 по 22.01. Никакой реакции не обнаружено.</strike><br />
<br />
=== 24.12.2008 (замечания QA) ===<br />
# <strike>При включенном брандмауэре FTP-сервер не работает в пассивном режиме. Возможно, нужно прописать порты для пассивного режима на сервере явно и включить их по умолчанию в настройке брандмауэр</strike> -- проверить!<br />
# <strike>Прокси-сервер не пускает на порт 8080 (alterator) {{man|george}} (''примечание: прокси не будет пускать никуда, если его не настроить'')<br />
#: Ошибка в том, что порт 8080 никак не отражён в squid.conf<br />
#: <tt>sed -i '/ 443/{p;s/ 443/ 8080/}' /etc/squid/squid.conf</tt> </strike><br />
# В документации по FTP-серверу указать, какие папки доступны для записи (пути), а также как выложить файл на веб-сервер {{man|azol}}<br />
<br />
=== 23.12.2008 (результаты совещания) ===<br />
<br />
Решения совещания в ALT Linux 23 декабря 2008 года:<br />
<br />
# ALT Linux 4.1 Office Server не выпускать, до 15.01.09 доделать Школьный Сервер<br />
# Убрать все привязки и упоминания LDAP из веб-интерфейса Alterator (сами пакеты оставить)<br />
# Переработать импорт из Хронографа для поддержки импорта локальной базы пользователей (не LDAP)<br />
#: Это означает убрать одну из главных фич Школьного сервера. На мой взгляд -- недопустимо.<br />
#:: Не означает. Правда же, моё утверждение столь же голословно, как и ваше? Поясните, что именно, по вашему мнению, пропадает. george@. Пропадает единая база пользователей с указанием данных о них, в частности ролей. Для каждого сервиса все нужно указывать заново, а импорт из Хронографа дает лишь имена. Замечу. что это одно из главных пожеланий учителей и это то, что они имеют в случае сервера Windows. Неприлично выпускать продукт, заведомо уступающим конкурирующему даже в основных функциях. aen@<br />
#: Такой пафос здесь неуместен, т. к. по п. 2 у вас возражений нет, это раз. Никакой единой базы на момент совещания не было, так что никуда она бы не пропала, это два. Большая просьба на будущее выражаться понятнее. @george<br />
<br />
=== 28.01.2009 (cas) ===<br />
<br />
'''полужирным шрифтом выделены блокеры''' <br />
<br />
<br />
* <strike>Ненужный запрос сертификата для http://ip/alt-docs<br />
<br />
Нужный. А всё из-за кривой mediawiki, которая не умеет логиниться по https, поэтому теперь всё ходит через https, поэтому сертификат на всё.<br />
{{man|cas}} ладно, пусть едят кактусы</strike><br />
* Служба Samba по умолчанию выключена и не стартует автоматом<br />
<br />
Надо указать почему служба отключена и как её включить — {{man|azol}}<br />
<br />
* <strike>Необходимо перенести "Дата и время", "Часовой пояс" в группу "Система" {{man|slazav}}</strike><br />
* <strike>Необходимо перенести "Службы xinetd" в "Серверы" {{man|slazav}}</strike><br />
* После установки требуется вручную перезапустить служб slapd и nslcd<br />
<br />
В новой сборке уже не нужно ;)<br />
<br />
* Служба Squid по умолчанию выключена и не стартует автоматом<br />
<br />
Надо указать почему служба отключена и как её включить — {{man|azol}}<br />
<br />
* <strike>Не понятно, что означает нелокализованный параметр "State" для ftp в службах xinetd -- там вообще отвалилась странно локализация, к {{man|slazav}}</strike><br />
* Служба xinetd по умолчанию выключена и не стартует автоматом<br />
<br />
Надо указать почему служба отключена и как её включить — {{man|azol}}<br />
<br />
* <strike>Не локализовано описание службы nslcd {{man|cas}}</strike><br />
* <strike>Корявая локализация описания службы ethtool {{man|cas}}</strike><br />
* Невозможно создать пользователя по умолчанию<br />
<br />
Это к вопросу рестарта slapd и т.п. Зачем плодить пункты? Для придания ощущения, что "всё плохо, счастья в жизни больше не будет"?<br />
{{man|cas}}: откуда мне было знать про такую астральную связь? ;)<br />
{{man|mex3}}: Я вообще-то в джаббере предупреждала в списке known bugs. К тому же, ты их пунктом раньше не просто так перезапустил, а с чьего-то (Барабашки?) совета? И по какой причине? Не верю, что ты запустил Школьный сервер и тебе просто так стукнуло в голову поперезапускать nslcd и slapd %)<br />
<br />
* Не локализована в настройках системного администратора надпись "Upload SSH public key" {{man|slazav}}<br />
* Не срабатывают хуки для заполнения конфигурационных файлов nss_ldap и pam_ldap (не прописывается правильные настройки LDAP) {{man|slazav}} vs {{man|lsv}}, ага...<br />
* В надпись "Вы действительно хотите удалить <user>?" необходимо добавить "...пользователя.." {{man|slazav}}<br />
* Изменить порядок кнопок в диалоге удаления пользователя<br />
<br />
Какой правильный?<br />
{{man|cas}}: Удалить | отмена<br />
Почему наоборот - неправильно? По мне так в заведомо возможно вредоносных операциях стоит сначала (или на более видном месте) помещать кнопку отмены, и только после (или на менее видном) - продолжения операции.<br />
<br />
* Нет справки по импорту из Хронографа<br />
<br />
Ждём обновления бранча на altair...<br />
<br />
* Не аутентифицируются пользователи на сервере FTP<br />
<br />
А надо? Были выкрики "против" и только один "за" - от тебя... Это вообще security-вопрос...<br />
{{man|cas}}: тогда надо переделывать всю морду, чтобы сделать анонимный FTP.<br />
{{man|mex3}}: Он сейчас по умолчанию анонимный. Не анонимный включается по желанию. Из морды никак не следует, что он должен быть по умолчанию именно не анонимным (хотя имеет смысл отразить это в справке). Ну и если менять морду - то как?<br />
<br />
* '''При перезапуске slapd нужно перезапускать и nslcd (иначе пропадают все пользователи).'''<br />
<br />
to {{man|lsv}}: а имеет ли смысл перезапускать только nslcd?<br />
<br />
* '''Не аутентифицируются пользователи на сервере Samba'''<br />
<br />
Тут можно по-подробнее? какие пользователи и каким образом созданные?<br />
{{man|cas}}: у нас только одни пользователи. Из раздела "Учётные записи".<br />
{{man|mex3}}: Так они же не создаются? А в moodle/mediawiki они заходить могут?<br />
{{man|cas}}: Создаются после перезапуска nslcd. Но в Moodle: "LDAP-службы недоступны", в MediaWiki: "Неверный пароль"<br />
<br />
* При аутентификации через LDAP Samba вообще не доступна<br />
<br />
Тут тоже можно подробнее?<br />
{{man|cas}}: включить аутентификацию "LDAP" (кстати, по умолчанию она не используется) и перезапустить службу. После этого попробовать просмотреть ресурсы сервера по SMB.<br />
Ок. Это к {{man|manowar}}<br />
<br />
* Служба dovecot по умолчанию выключена и не стартует автоматом<br />
<br />
Надо указать почему служба отключена и как её включить — {{man|azol}}<br />
<br />
* Неправильная надпись в модуле настройки "Центр управления системой": "Забрать запрос на подпись". Нужно "Скачать запрос на подпись" {{man|slazav}}<br />
* Нет справки для модуля "Центр управления системой"<br />
* '''Не аутентифицируются пользователи на сервере dovecot (POP)'''<br />
<br />
опять же, ну почему нельзя написать сразу подробнее? Какие пользователи, какие настройки? Может, они и не должны?<br />
{{man|cas}}: см. выше. У нас одни пользователи.<br />
{{man|mex3}}: тогда жду ответа выше же :)<br />
<br />
* '''Не аутентифицируются пользователи в Moodle''' (LDAP-module cannot connect to any servers)<br />
* '''Не аутентифицируются пользователи в MediaWiki''' (неверный пароль)<br />
<br />
{{succession box<br />
|wide = 1<br />
|title = {{nobr|ALT Linux 4.1 Office Server}}<br />
|years = {{nobr| 2008 —}} {{nobr| }}<br />
|before = [[ALT Linux 4.0 Office Server]] <!-- поправьте тут --><br />
|after = [[ALT Linux 5.0 Office Server]] <!-- поправьте тут --><br />
|category = ALT Linux Office Server<br />
}}<br />
<br />
{{Category navigation|title=Версия 4.1|category=Версия 4.1}}<br />
{{Category navigation|title=ALT Linux Office Server|category=ALT Linux Office Server}}</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8707Alterator/l10n2009-01-28T09:36:20Z<p>VladislavZavjalov: /* Новая схема */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== Справка ==<br />
<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== Переводы ==<br />
<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы автоматически берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
Новая схема решает все эти проблемы.<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo, xinetd, services, samba}<br />
<br />
С точки зрения мейнтейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»).<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»).<br />
* Находясь в alterator-l10n обновляем словарь своего модуля модуля: '''./update_module <директория с модулем>''' (директория с модулем — та, в которой живет Makefile). При этом недостающие переводы берутся из общего словаря.<br />
* При первом запуске update_module (если словаря для этого модуля еще нет в alterator-l10n), словарь берется из модуля.<br />
* Правим словарь своего модуля в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы опять возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все словари модулей)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит только внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Некоторая особенность связана с переводами полей {{term|Name}} и {{term|Comment}} в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придётся каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт {{cmd|./update_desktop <директория с модулем>}} мы обновляем desktop-файлы модуля…<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь также используется для построения словарей модулей в старой схеме, это лучше делать хитрее и вручную.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=%D0%A4%D0%B0%D0%B9%D0%BB:Alterator-l10n-pr1.png&diff=8655Файл:Alterator-l10n-pr1.png2009-01-26T12:56:45Z<p>VladislavZavjalov: загружена новая версия «Изображение:Alterator-l10n-pr1.png»</p>
<hr />
<div>вариант обустройства модуля alterator-l10n</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8652Alterator/l10n2009-01-26T11:38:15Z<p>VladislavZavjalov: /* Новая схема */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== Справка ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== Переводы ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы автоматически берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
Новая схема решает все эти проблемы.<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo,xinetd,services,samba}<br />
<br />
С точки зрения мантейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»).<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»).<br />
* Находясь в alterator-l10n обновляем словарь своего модуля модуля: '''./update_module <директория с модулем>''' (директория с модулем -- та, в которой живет Makefile). При этом недостающие переводы берутся из общего словаря.<br />
* Правим словарь своего модуля в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы опять возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все словари модулей)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит только внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Некоторая особенность связана с переводами полей Name и Comment в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придется каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт './update_desktop <директория с модулем>' мы обновляем desktop-файлы модуля...<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь также используется для построения словарей модулей в старой схеме, это лучше делать хитрее и вручную.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8651Alterator/l10n2009-01-26T11:35:34Z<p>VladislavZavjalov: /* help */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== Справка ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== Переводы ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы автоматически берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
Новая схема решает все эти проблемы.<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo,xinetd,services,samba}<br />
<br />
С точки зрения мантейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»).<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»).<br />
* Находясь в alterator-l10n обновляем словарь своего модуля модуля: '''./update_module <директория с модулем>''' (директория с модулем -- та, в которой живет Makefile). При этом недостающие переводы берутся из общего словаря.<br />
* Правим словарь своего модуля в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы опять возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все словари модулей)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит только внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Некоторая особенность связана с переводами полей Name и Comment в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придется каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт './update_desktop <директория с модулем>' мы обновляем desktop-файлы модуля...<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь используется для построения словарей модулей в старой схеме, это не нужно делать.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8650Alterator/l10n2009-01-26T11:35:22Z<p>VladislavZavjalov: /* Новая схема */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== Переводы ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы автоматически берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
Новая схема решает все эти проблемы.<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo,xinetd,services,samba}<br />
<br />
С точки зрения мантейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»).<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»).<br />
* Находясь в alterator-l10n обновляем словарь своего модуля модуля: '''./update_module <директория с модулем>''' (директория с модулем -- та, в которой живет Makefile). При этом недостающие переводы берутся из общего словаря.<br />
* Правим словарь своего модуля в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы опять возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все словари модулей)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит только внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Некоторая особенность связана с переводами полей Name и Comment в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придется каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт './update_desktop <директория с модулем>' мы обновляем desktop-файлы модуля...<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь используется для построения словарей модулей в старой схеме, это не нужно делать.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8649Alterator/l10n2009-01-26T11:32:51Z<p>VladislavZavjalov: /* Новая схема */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== Переводы ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы автоматически берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
Новая схема решает все эти проблемы.<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo,xinetd,services,samba}<br />
<br />
С точки зрения мантейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»).<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»).<br />
* Находясь в alterator-l10n обновляем словарь своего модуля модуля: '''./update_module <директория с модулем>'''. При этом недостающие переводы берутся из общего словаря. (Директория с модулем - та, в которой живет Makefile)<br />
* Правим переводы, относящиеся только к своему модулю в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все словари модулей)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Некоторая особенность связана с переводами полей Name и Comment в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придется каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт './update_desktop <директория с модулем>' мы обновляем desktop-файлы модуля...<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь используется для построения словарей модулей в старой схеме, это не нужно делать.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8648Alterator/l10n2009-01-26T11:24:40Z<p>VladislavZavjalov: /* Переводы */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== Переводы ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы автоматически берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
Новая схема решает все эти проблемы.<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo,xinetd,services,samba}<br />
<br />
С точки зрения мантейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»).<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»).<br />
* Находясь в alterator-l10n обновляем словарь своего модуля модуля: '''./update_module <директория с модулем>'''. При этом недостающие переводы берутся из общего словаря. (Директория с модулем - та, в которой живет Makefile)<br />
* Правим переводы, относящиеся только к своему модулю в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все словари модулей)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
Некоторая особенность связана с переводами полей Name и Comment в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придется каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт './update_desktop <директория с модулем>' мы обновляем desktop-файлы модуля...<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь используется для построения словарей модулей в старой схеме, это не нужно делать.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8647Alterator/l10n2009-01-26T11:23:40Z<p>VladislavZavjalov: /* Недостатки старой схемы */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== Переводы ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы автоматически берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
Новая схема решает все эти проблемы.<br />
<br />
=== Предложение новой схемы ===<br />
* утилита update-module, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.<br />
* тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…<br />
* при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo,xinetd,services,samba}<br />
<br />
С точки зрения мантейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»).<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»).<br />
* Находясь в alterator-l10n обновляем словарь своего модуля модуля: '''./update_module <директория с модулем>'''. При этом недостающие переводы берутся из общего словаря. (Директория с модулем - та, в которой живет Makefile)<br />
* Правим переводы, относящиеся только к своему модулю в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все модули)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
Некоторая особенность связана с переводами полей Name и Comment в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придется каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт './update_desktop <директория с модулем>' мы обновляем desktop-файлы модуля...<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь используется для построения словарей модулей в старой схеме, это не нужно делать.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8646Alterator/l10n2009-01-26T11:23:19Z<p>VladislavZavjalov: /* Новая схема */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== Переводы ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы автоматически берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
=== Предложение новой схемы ===<br />
* утилита update-module, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.<br />
* тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…<br />
* при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo,xinetd,services,samba}<br />
<br />
С точки зрения мантейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»).<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»).<br />
* Находясь в alterator-l10n обновляем словарь своего модуля модуля: '''./update_module <директория с модулем>'''. При этом недостающие переводы берутся из общего словаря. (Директория с модулем - та, в которой живет Makefile)<br />
* Правим переводы, относящиеся только к своему модулю в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все модули)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
Некоторая особенность связана с переводами полей Name и Comment в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придется каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт './update_desktop <директория с модулем>' мы обновляем desktop-файлы модуля...<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь используется для построения словарей модулей в старой схеме, это не нужно делать.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8645Alterator/l10n2009-01-26T11:20:59Z<p>VladislavZavjalov: /* Старая схема */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== Переводы ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы автоматически берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
=== Предложение новой схемы ===<br />
* утилита update-module, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.<br />
* тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…<br />
* при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo,xinetd,services,samba}<br />
<br />
С точки зрения мантейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»)<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»)<br />
* Находясь в alterator-l10n обновляем переводы из модуля: '''./update_module <директория с модулем>'''. При этом недостающие переводы берутся из общего словаря<br />
* Правим переводы, относящиеся только к своему модулю в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все модули)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
Некоторая особенность связана с переводами полей Name и Comment в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придется каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт './update_desktop <директория с модулем>' мы обновляем desktop-файлы модуля...<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь используется для построения словарей модулей в старой схеме, это не нужно делать.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8644Alterator/l10n2009-01-26T11:20:31Z<p>VladislavZavjalov: /* po */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== Переводы ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
=== Предложение новой схемы ===<br />
* утилита update-module, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.<br />
* тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…<br />
* при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo,xinetd,services,samba}<br />
<br />
С точки зрения мантейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»)<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»)<br />
* Находясь в alterator-l10n обновляем переводы из модуля: '''./update_module <директория с модулем>'''. При этом недостающие переводы берутся из общего словаря<br />
* Правим переводы, относящиеся только к своему модулю в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все модули)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
Некоторая особенность связана с переводами полей Name и Comment в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придется каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт './update_desktop <директория с модулем>' мы обновляем desktop-файлы модуля...<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь используется для построения словарей модулей в старой схеме, это не нужно делать.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8643Alterator/l10n2009-01-26T11:19:54Z<p>VladislavZavjalov: /* Старая схема */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== po ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
=== Предложение новой схемы ===<br />
* утилита update-module, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.<br />
* тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…<br />
* при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo,xinetd,services,samba}<br />
<br />
С точки зрения мантейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»)<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»)<br />
* Находясь в alterator-l10n обновляем переводы из модуля: '''./update_module <директория с модулем>'''. При этом недостающие переводы берутся из общего словаря<br />
* Правим переводы, относящиеся только к своему модулю в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все модули)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
Некоторая особенность связана с переводами полей Name и Comment в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придется каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт './update_desktop <директория с модулем>' мы обновляем desktop-файлы модуля...<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь используется для построения словарей модулей в старой схеме, это не нужно делать.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8642Alterator/l10n2009-01-26T11:19:43Z<p>VladislavZavjalov: /* Старая схема */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы автоматически берутся из {{path|/usr/share/alterator/l10n/help/}} (см.) и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== po ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
=== Предложение новой схемы ===<br />
* утилита update-module, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.<br />
* тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…<br />
* при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo,xinetd,services,samba}<br />
<br />
С точки зрения мантейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»)<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»)<br />
* Находясь в alterator-l10n обновляем переводы из модуля: '''./update_module <директория с модулем>'''. При этом недостающие переводы берутся из общего словаря<br />
* Правим переводы, относящиеся только к своему модулю в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все модули)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
Некоторая особенность связана с переводами полей Name и Comment в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придется каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт './update_desktop <директория с модулем>' мы обновляем desktop-файлы модуля...<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь используется для построения словарей модулей в старой схеме, это не нужно делать.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8641Alterator/l10n2009-01-26T11:19:09Z<p>VladislavZavjalov: </p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы берутся из {{path|/usr/share/alterator/l10n/help/}} (см.) и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== po ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
=== Предложение новой схемы ===<br />
* утилита update-module, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.<br />
* тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…<br />
* при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo,xinetd,services,samba}<br />
<br />
С точки зрения мантейнера модуля устроено так:<br />
<br />
* В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»)<br />
* Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»)<br />
* Находясь в alterator-l10n обновляем переводы из модуля: '''./update_module <директория с модулем>'''. При этом недостающие переводы берутся из общего словаря<br />
* Правим переводы, относящиеся только к своему модулю в alterator-l10n/po/<язык>/<имя>.po<br />
* Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n<br />
* При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы возьмутся из общего словаря.<br />
<br />
С точки зрения переводчика:<br />
* можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все модули)<br />
* можно править переводы в модулях<br />
* можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности<br />
* Все это происходит внутри alterator-l10n, при изменениях модули пересобирать не нужно.<br />
<br />
Некоторая особенность связана с переводами полей Name и Comment в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придется каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.<br />
<br />
Сейчас сделано так:<br />
* строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.<br />
* запуская в alterator-l10n скрипт './update_desktop <директория с модулем>' мы обновляем desktop-файлы модуля...<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь используется для построения словарей модулей в старой схеме, это не нужно делать.<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8624Alterator/l10n2009-01-23T15:47:16Z<p>VladislavZavjalov: /* Предложение новой схемы */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы берутся из {{path|/usr/share/alterator/l10n/help/}} (см.) и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== po ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
=== Предложение новой схемы ===<br />
В alterator-l10n находится следующее:<br />
* общий словарь (обновляется редко, «переводчиками»)<br />
* отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»)<br />
* утилита update-module, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.<br />
* тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…<br />
* при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.<br />
<br />
Кажется, это решает все перечисленные проблемы.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована. На неё переведены модули alterator-{x11,lilo}<br />
<br />
Работает так:<br />
<br />
* находясь в alterator-l10n обновляем переводы из модуля: '''./update_module <директория с модулем>'''. при этом недостающие переводы берутся из общего словаря<br />
* правим переводы, относящиеся только к своему модулю в alterator-l10n/po/<язык>/<имя>.po<br />
* коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* из своего модуля убираем паковку mo-файлов и (если уже и хелп переведён на новую схему) сборочную зависимость на alterator-l10n<br />
* при сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы опять берутся из общего словаря.<br />
<br />
Оставшиеся проблемы:<br />
* скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке (это, кажется совсем простым, сделаю в ближайшее время)<br />
* перевод desktop-файлов (у меня идей пока нет :()<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8618Alterator/l10n2009-01-23T08:28:16Z<p>VladislavZavjalov: /* Новая схема */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы берутся из {{path|/usr/share/alterator/l10n/help/}} (см.) и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== po ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
=== Предложение новой схемы ===<br />
В alterator-l10n находится следующее:<br />
* общий словарь (обновляется редко, «переводчиками»)<br />
* отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»)<br />
* утилита update-po, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.<br />
* тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…<br />
* при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.<br />
<br />
Кажется, это решает все перечисленные проблемы.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
<br />
=== Новая схема ===<br />
В данный момент новая схема почти реализована. На неё переведены модули alterator-{x11,lilo}<br />
<br />
Работает так:<br />
<br />
* находясь в alterator-l10n обновляем переводы из модуля: '''./update_module <директория с модулем>'''. при этом недостающие переводы берутся из общего словаря<br />
* правим переводы, относящиеся только к своему модулю в alterator-l10n/po/<язык>/<имя>.po<br />
* коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…<br />
* из своего модуля убираем паковку mo-файлов и (если уже и хелп переведён на новую схему) сборочную зависимость на alterator-l10n<br />
* при сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы опять берутся из общего словаря.<br />
<br />
Оставшиеся проблемы:<br />
* скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке (это, кажется совсем простым, сделаю в ближайшее время)<br />
* перевод desktop-файлов (у меня идей пока нет :()<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8605Alterator/l10n2009-01-22T17:57:25Z<p>VladislavZavjalov: /* В данный момент новая схема почти реализована. На нее переведены модули alterator-{x11,lilo} */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы берутся из {{path|/usr/share/alterator/l10n/help/}} (см.) и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== po ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
=== Предложение новой схемы ===<br />
В alterator-l10n находится следующее:<br />
* общий словарь (обновляется редко, «переводчиками»)<br />
* отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»)<br />
* утилита update-po, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.<br />
* тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…<br />
* при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.<br />
<br />
Кажется, это решает все перечисленные проблемы.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
<br />
=== В данный момент новая схема почти реализована. На нее переведены модули alterator-{x11,lilo} ===<br />
<br />
Работает так:<br />
<br />
* находясь в alterator-l10n обновляем переводы из модуля: '''./update_module <директория с модулем>'''. при этом недостающие переводы берутся из общего словаря<br />
* правим переводы, относящиеся только к своему модулю в alterator-l10n/po/<имя>.po<br />
* коммитим, пушим, просим мантейнера alterator-l10n втянуть...<br />
* из своего модуля убираем паковку mo-файлов и (если уже и хелп переведен на новую схему) сборочную зависимость на alterator-l10n<br />
* при сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причем недостающие переводы опять берутся из общего словаря.<br />
<br />
Оставшиеся проблемы:<br />
* скрипт для сливания общего словаря из всех модулей - синяя стрелка на картинке (это, кажется совсем простым, сделаю в ближайшее время)<br />
* перевод desktop-файлов (у меня идей пока нет :( )<br />
<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8604Alterator/l10n2009-01-22T17:52:22Z<p>VladislavZavjalov: /* В данный момент новая схема почти реализована. На нее переведены модули alterator-{x11,lilo} */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы берутся из {{path|/usr/share/alterator/l10n/help/}} (см.) и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== po ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
=== Предложение новой схемы ===<br />
В alterator-l10n находится следующее:<br />
* общий словарь (обновляется редко, «переводчиками»)<br />
* отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»)<br />
* утилита update-po, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.<br />
* тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…<br />
* при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.<br />
<br />
Кажется, это решает все перечисленные проблемы.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
<br />
=== В данный момент новая схема почти реализована. На нее переведены модули alterator-{x11,lilo} ===<br />
<br />
Работает так:<br />
<br />
* обновляем переводы из модуля: '''update_module <директория с модулем>'''. при этом недостающие переводы берутся из общего словаря<br />
* правим переводы, относящиеся только к модулю в alterator-l10n/po/<имя>.po<br />
* коммитим, пушим, просим мантейнера втянуть...<br />
* из своего модуля убираем паковку mo-файлов и сборочную зависимость на alterator-l10n (если уже и хелп переведен на новую схему)<br />
* при сборке alterator-l10n для каждого модуля собираются и устанавливаются в систему mo-файлы. Причем недостающие переводы опять берутся из общего словаря.<br />
<br />
Оставшиеся проблемы:<br />
* скрипт для сливания общего словаря из всех модулей - синяя стрелка на картинке (это, кажется совсем простым, сделаю в ближайшее время)<br />
* перевод desktop-файлов (у меня идей пока нет :( )<br />
<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8603Alterator/l10n2009-01-22T17:51:34Z<p>VladislavZavjalov: /* Предложение новой схемы */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы берутся из {{path|/usr/share/alterator/l10n/help/}} (см.) и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== po ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
=== Предложение новой схемы ===<br />
В alterator-l10n находится следующее:<br />
* общий словарь (обновляется редко, «переводчиками»)<br />
* отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»)<br />
* утилита update-po, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.<br />
* тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…<br />
* при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.<br />
<br />
Кажется, это решает все перечисленные проблемы.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
<br />
=== В данный момент новая схема почти реализована. На нее переведены модули alterator-{x11,lilo} ===<br />
<br />
Работает так:<br />
<br />
* обновляем переводы из модуля: '''update_module <директория с модулем>'''. при этом недостающие переводы берутся из общего словаря<br />
* правим переводы, относящиеся только к модулю в alterator-l10n/po/<имя>.po<br />
* коммитим, пушим, просим мантейнера втянуть...<br />
* из своего модуля убираем паковку mo-файлов и сборочную зависимость на alterator-l10n (если уже и хелп переведен на новую схему)<br />
* при сборке alterator-l10n для каждого модуля собираются и устанавливаются в систему mo-файлы. Причем недостающие переводы опять берутся из общего словаря.<br />
<br />
Оставшиеся проблемы:<br />
* скрипт для сливания общего словаря из всех модулей (это, кажется совсем простым, сделаю в ближайшее время)<br />
* перевод desktop-файлов (у меня идей пока нет :( )<br />
<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8590Alterator/l10n2009-01-21T15:51:33Z<p>VladislavZavjalov: /* Новая схема */</p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы берутся из {{path|/usr/share/alterator/l10n/help/}} (см.) и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== po ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
=== Предложение новой схемы ===<br />
В alterator-l10n находится следующее:<br />
* общий словарь (обновляется редко, «переводчиками»)<br />
* отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»)<br />
* утилита update-po, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.<br />
* тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…<br />
* при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.<br />
<br />
Кажется, это решает все перечисленные проблемы.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalovhttps://www.altlinux.org/index.php?title=Alterator/l10n&diff=8587Alterator/l10n2009-01-21T13:52:41Z<p>VladislavZavjalov: </p>
<hr />
<div>'''alterator-l10n'''<br />
<br />
== help ==<br />
=== Старая схема ===<br />
* хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию {{path|/usr/share/alterator/l10n/help/}} и ''не'' используются альтератором<br />
* модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля хелпы берутся из {{path|/usr/share/alterator/l10n/help/}} (см.) и устанавливаются в директорию {{path|/usr/share/alterator/help/}}, где их и ищет альтератор.<br />
*: (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)<br />
<br />
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.<br />
<br />
=== Новая схема ===<br />
* Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в {{path|/usr/share/alterator/help/}}<br />
<br />
При правке хелпа и пересборки модуля не требуется.<br />
<br />
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета {{pkg|alterator-l10n}} сделаны директории {{path|old_help}} и {{path|new_help}}. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.<br />
<br />
== po ==<br />
=== Старая схема ===<br />
* словарь, общий для всех модулей, лежит в alterator-l10n<br />
* существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.<br />
* модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n<br />
* при сборке модуля переводы берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.<br />
<br />
=== Недостатки старой схемы ===<br />
* При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.<br />
* При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.<br />
* «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n<br />
* «Общий» файл переводов неудобно переводить без контекста.<br />
* В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.<br />
<br />
=== Предложение новой схемы ===<br />
В alterator-l10n находится следующее:<br />
* общий словарь (обновляется редко, «переводчиками»)<br />
* отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»)<br />
* утилита update-po, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.<br />
* тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…<br />
* при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.<br />
<br />
Кажется, это решает все перечисленные проблемы.<br />
<br />
[[Изображение:alterator-l10n-pr1.png]]<br />
<br />
[[Категория:Sisyphus]]</div>VladislavZavjalov