Автоматично, по запиту клієнта, створювати переклад для якоїсь версії програми, використовуючи головний uk.po програми і en.po для конкретної версії. Кешувати результат.Автоматично приймати чи брати переклади з різних джерел. Зберігати переклади з різних джерел у різних файлах і автоматично зливати їх у один uk.po сортуючи їх по даті редагування.
теоретично, перше має полегшити життя супровідників пакунків, але не робить цього, оскільки доведеться накладати якусь латку на застарілі стабільні пакунки без особливої причини (можливо, я не правий, і це має полегшити життя користувачів, але це у перспективі призведе до простого множення тих, хто нічого не планує робити, але хоче всього готового).
дуже часто важливим є не лише саме повідомлення, але і його контекст (сусідні повідомлення з того самого файла). Чудове пояснення Часлава Іліча. Тому такі переклади не лише важко буде перевіряти, вони, найімовірніше, міститимуть жахливі невлучання за контекстом.
Цитата: yurchor від 2011-01-20 19:23:37теоретично, перше має полегшити життя супровідників пакунків, але не робить цього, оскільки доведеться накладати якусь латку на застарілі стабільні пакунки без особливої причини (можливо, я не правий, і це має полегшити життя користувачів, але це у перспективі призведе до простого множення тих, хто нічого не планує робити, але хоче всього готового).Трохи навпаки — не доведеться накладати латки на старі (чи нові) версії пакунків, оскільки переклади будуть йти окремим каналом розповсюдження.
Цитата: yurchor від 2011-01-20 19:23:37дуже часто важливим є не лише саме повідомлення, але і його контекст (сусідні повідомлення з того самого файла). Чудове пояснення Часлава Іліча. Тому такі переклади не лише важко буде перевіряти, вони, найімовірніше, міститимуть жахливі невлучання за контекстом.В більшості випадків, це буде той самий .po, який іде з останньою версією програми. В деяких випадках, він міститиме якісь правки, внесені модераторами чи іншими перекладачами, які ще не потрапили в останню версію. Я не бачу ніяких нових проблем з цим підходом, крім проблеми конфлікту двох перекладів від різних перекладачів, яку мають вирішувати або перекладачі або модератор.Система призначена для того, щоб якщо якесь поновлення чи виправлення було зроблено зараз, то користувачі мають побачити його сьогодні ж або завтра.В мене, напр., немає ніякого бажання правити переклад, якщо я знаю, що наступне оновлення системи його затре, що на інших моїх комп’ютерах я його не побачу, і що в дистрибутив воно попаде десь за півроку в кращому випадку, якщо я буду дуже напористий через ці пару слів.
Боюся на такий велосипед майже ніхто не підпишеться.
У більшої частини є LP, де тепер роблять те саме: останні зміни у Rosetta від Даніли Шегана полягають у тому, що Rosetta бомбардує git GNOME і таскає будь-які переклади, які там робляться, ледве не раз на день (швидше ніж вони потраплять до самого GNOME). Фактично, Ubuntu ставить ультиматум всім перекладачам основних гілок: або беріть переклади з Rosetta, або залишайтеся без сторонніх перекладів (сподівайтеся лише на користувачів інших дистрибутивів).
На мій же погляд, відокремлення перекладів від самих програм є згубним: перекладачі можуть бути корисними авторам програм, — виправляти вади, друкарські помилки, допомагати у локалізації.
— Лікарю, а я зможу після операції грати на піаніно?— Так, звичайно, це легка операція.— Дивно, а до операції я не міг. :-/
Крім того, виокремлення так званих «мовних пакунків» не вирішує проблем з багатьма програмами, де переклад має бути зібрано разом з програмою (більшість програм, що використовують intltool того-таки Даніли Шегана). Серед таких програм Audacity, Inkscape, всі програми з комплекту GNOME, частина програм TP (зокрема grub 2). Що робити з ними? Під час приготування Ubuntu 10.04 Canonical вже наскочила на ці граблі, повторимо подвиг?
Ну, і що робити з виправленим перекладом?
Цитата: yurchor від 2011-01-21 12:00:54На мій же погляд, відокремлення перекладів від самих програм є згубним: перекладачі можуть бути корисними авторам програм, — виправляти вади, друкарські помилки, допомагати у локалізації.Цитата— Лікарю, а я зможу після операції грати на піаніно?— Так, звичайно, це легка операція.— Дивно, а до операції я не міг. :-/
Цитата: yurchor від 2011-01-21 12:00:54Крім того, виокремлення так званих «мовних пакунків» не вирішує проблем з багатьма програмами, де переклад має бути зібрано разом з програмою (більшість програм, що використовують intltool того-таки Даніли Шегана). Серед таких програм Audacity, Inkscape, всі програми з комплекту GNOME, частина програм TP (зокрема grub 2). Що робити з ними? Під час приготування Ubuntu 10.04 Canonical вже наскочила на ці граблі, повторимо подвиг?Дайте посилання на цю проблему, бо це якась дуже серйозна помилка в intltool, про яку я нічого не знаю. :-/
Цитата: yurchor від 2011-01-21 12:00:54Ну, і що робити з виправленим перекладом?Те саме, що й завжди: залити його в git Ґнома, звідки його візьме Розета, звідки його стягне моя система на сервері, звідки його візьме мій клієнт на моїх комп’ютерах, і де, нарешті, його побачу я.
