PFS-utils на github

[sfs]

не умеет ничего выводить кроме имени пользователя и значков пароля.

"Пароль неправильный" и т.п.

[Pro]

пока его переведешь, ты уже что-то другое вкорячишь вместо.

[sfs]

Кто хочет, тот ищет возможности, кто не хочет — ищет причины
Я и pfs постоянно переделываю 
Весь линукс обновляется - отличная "причина"

[Pro]

Кто хочет, тот ищет возможности, кто не хочет — ищет причины

именно поэтому я делаю то что мне нравится в настоящий момент.

[Zay]

А не пора ли отказаться от /usr/sbin ?

Это не очень сложно сделать. Но есть смысл делать оптимизацию комплексом.
Например слить тестовую ветку (от ander) с основной. Но сначала протестировать всё, изменений много, наверняка есть подводные камни.

...продолжить перевод через gettext или лучше сделать перевод методом через переменные...

У меня была мысль разделить консольную и графическую часть PFS-utils (это вполне возможно).
Консольную часть переводить не нужно (изначально на англ., и это нормально), а к графической можно gettext прикрутить.

[Pro]

У меня была мысль разделить консольную и графическую часть PFS-utils (это вполне возможно).

оно уже разделено же вроде, то что с _pfs то графическое.

а к графической можно gettext прикрутить.

ну подсказывай когда можно начинать, я форкну.

[sfs]

Если уж заморачиваться gettext - сначала надо объединить все 3 варианта pfs : Zay ander PRA

[Zay]

оно уже разделено же вроде, то что с _pfs то графическое.

Да, я про разделение на уровне GitHub'а.
Консольным утилитам перевод не нужен, в то же время они самые важные с точки зрения функционала.

Кстати, заодно с разделением можно было бы и "отказаться от /usr/sbin" без дополнительных проблем.

ну подсказывай когда можно начинать, я форкну.

Когда угодно. Вроде бы ander не переделывал GUI-часть скриптов.
Но лучше заранее решить - нужно ли разделение на два [под]проекта. Чтобы потом мержить спокойно.

надо объединить все 3 варианта pfs

А это, похоже, совсем не просто. Вот потому я и заговорил про разделение на консоль и GUI.

GUI тогда можно будет спокойно править, переводить на gettext и т.п.
А основные консольные утилиты - менять только по согласованию, с проверками, чтобы исключить ошибки.

[Pro]

Когда угодно.

Сделал поддержку gettext для скриптов.

Прошу простить что сразу в master ветку закоммитил, надо было в тестинг конечно же

[Pro]

Возникли проблемы при локализации, открыл issue
Помогите.

[Zay]

Отписал в issue для пробы.

[Pro]

запилил локализацию. Мастер sfs не изволишь ли забрать локализованные скрипты?

Zay, скрипты я доправил в master ветке, файлы переводов ложил в тестинг.

открыл новый issue. надо обдумать.

[sfs]

За основу были взяты скрипты из ПРА? Там могли быть незначительные отличия. Предлагаю добавлять локализованное в  089en-Pra-update (составной) , а выбор локали вынести в параметр ядра lang= (по дефолту ru.RU-UTF8)
Давай я сделаю lang= , а ты 089en-Pra-update

[Pro]

За основу были взяты скрипты из ПРА?

нет конечно, за основу были взяты скрипты из master ветки на гитхабе.

Предлагаю добавлять локализованное в  089en-Pra-update (составной)

одно да потому, обсуждали уже. Ты против локализации или чего? против того что нерусский дядя твой скрипт прочитает? ЛОГИКА ГДЕ БЛЯХА?

а выбор локали вынести в параметр ядра lang=

ну можно, а также load=, noload= есть ничем не хуже.

[sfs]

нет конечно, за основу были взяты скрипты из master ветки на гитхабе.

Как теперь быть с патчами ПРа?
089en-Pra-update - для удобства тестирования. Не хочется запороть локализацией уже достаточно стабильный дистр
Я за локализацию (см. голосование)
lang= даст возможность формировать /etc/locale.conf при старте и соответственно возможность тестировать локализованные скрипты под русской локалью. Иначе придется /etc/locale.conf пихать в сохраненку (уменьшит к-во тестеров)
В варианте 089en-Pra-update  + lang= реально поставить в исо 1505