Як впорядкувати рядкові ресурси локалізації?

Ми розробляємо великий додаток, що складається з безлічі невеликих пакетів. Кожен пакет має власний набір файлів ресурсів для локалізації.

Який найкращий підхід до організації та називання рядків локалізації?

Ось мої думки поки що:

Поводження з дублікатами

Один і той же текст (скажімо, "поштовий індекс") може виникати кілька разів у межах певного пакету. Інстинкт програмування (DRY) підказує мені створити єдиний рядовий ресурс, спільний для всіх подій .

Потім перекладач може захотіти вибрати довгий переклад ("Postleitzahl") в деяких місцях і коротший ("PLZ") в місцях з меншим простором. Або ми можемо вирішити додати двокрапку до деяких подій ("Поштовий індекс:"), але не до інших. Або нам може знадобитися інша капіталізація ("поштовий індекс") в деяких місцях. Усі ці аргументи вказують на створення одного ресурсу за використання, навіть якщо їхній вміст однаковий .

Іменування

Якщо ми прагнемо усунути дублікати, має сенс називати ресурси за вмістом , можливо, натякаючи на тип використання за допомогою префікса. Таким чином, у нас може бути labelOK= "ОК" , messageFileTooLarge= "Файл перевищує максимальний розмір файлу." , і labelZipCode= "Поштовий індекс" .

Ім'я за вмістом має перевагу природним чином обробляти аргументи формату: ресурс messageFileHas_0_MBWhileMaximumIs_1_MBчітко приймає два аргументи форматування, фактичний розмір файлу та максимальний розмір файлу.

Якщо ми дозволяємо дублікати, однак називати лише вмістом не має сенсу. Для того, щоб отримати унікальні імена ресурсів, нам потрібно якось включити місце використання у ім’я ресурсу. Це працює для графічних елементів керування, хоча ідентифікатори мають тенденцію отримати трохи довгі: fileSelectionConfirmationButtonText= "ОК" , customerDetailsTableColumnZipCode= "Поштовий індекс" . Однак для невізуальних файлів коду стає складніше. Як ви називаєте конкретне використання рядка, якщо ви не знаєте, де воно в кінцевому підсумку відображатиметься? За кодовим файлом та назвою функції? Мені здається досить незграбним і крихким.

Загалом, я схиляюся до дозволу дублікатів, але я намагаюся знайти послідовну схему іменування, яка це підтримує.

Редагувати: Це запитання має два аспекти: як організувати ресурси (DRY проти дублікатів) та як їх називати . Поки відповіді були зосереджені на першому аспекті. Буду вдячний за відгуки щодо конвенцій про іменування!

Я б приймав дублювання, коли ви не можете бути абсолютно впевнені, що значення абсолютно однакове у всіх випадках використовується певна рядок.

Навіть якщо два ярлики завжди містять однаковий рядок англійською мовою (або рідною мовою), вони не обов'язково будуть однаковими для всіх мов. Прийняття дублювання може дати вам (а точніше перекладачам) гнучкість, необхідну для вирішення таких ситуацій.

Як приклад: Розгляньте етикетку "Умова", яка, в залежності від контексту, може бути переведена на "Zustand" або "Bedingung" німецькою мовою (серед безлічі інших можливих перекладів).

Прийміть кілька дублікатів.

Ви можете уникнути декількох перекладів, створивши додаткові елементи керування. Напр. A CancelButtonі an, OKButtonякі вже містять їх текст, і тепер Скасувати / Скоротити OK / OK потрібно перекласти лише один раз. Але це майже особливий випадок.

Ось як ми впораємося з цим у моїй компанії:

Конвенція про іменування: ми називаємо мітки, префіксуючи їх класом / секцією / формою / тощо. Наприклад loadFile_loadButton, loadFile_fileNameLabel, loadFile_cancelвсі ярлики , що належать до діалогу Load File. Хоча ця підкреслена конвенція щодо іменування не є найпоширенішою, ми віддаємо перевагу їй над більш стандартними умовами, оскільки це покращує читабельність та "групуваність": зауважте, як легко зрозуміти, до якого елемента належать мітки та що кожна позначка являє, порівняно з мітками названий loadFileLoadButton, loadFileNameLabelі loadFileCancel. Ви можете подумати, що різниця не така велика, але коли у вас тисячі етикеток, складний ефект того вартий.

Коментарі до заголовків: Крім префіксації назв міток, ми також додаємо коментарі до заголовків до файлів ресурсів, щоб чітко визначити групування міток. Таким чином, хтось хоче змінити або додати конкретні мітки, пов’язані з певним класом / секцією / формою / тощо, може знайти всі мітки, пов’язані з цим конкретним елементом, лише в одному місці, під одним заголовком, і може легко перейти до додавання чи зміни міток знаючи, що вони не порушать перекладів для будь-яких інших елементів (IMHO, це також є дуже сильним моментом щодо того, чому потрібно дозволити дублювання).

"Виправдані" дублікати бажані: Як було сказано вище, ці практики остаточно призведуть до дублювання міток, але ми з цим не бачимо жодних проблем (докладніше про те, як впоратися з цим в Інструментах торгівлі).

Як зазначали інші, одна мітка однією мовою може бути перекладена двома або більше різними способами іншими мовами, залежно від контексту, який вони представлені. Якщо ви "уніфікуєте" мітки, перекладачеві буде справді важко придумати єдину мітку, яка вміщує всі контексти, де вона знайдена. Отже, як ми бачимо, надання «виправданих» дублікатів сприяє поліпшенню якості локалізації, якщо вони не посилаються на одне і те саме в одному контексті (це значення «виправданого»).

Інструменти торгівлі: щоб бути максимально ефективним під час перекладу, ви можете створити власний інструмент, який шукає подібні мітки, що існують у ваших пакетах, і запропонувати їх переклади як значення за замовчуванням для нових міток, або ви навіть можете використовувати існуючі сервіси на зразок цього , які надають такі інструменти, як той, про який я щойно згадував, роблячи переклад нових міток легким вітром (тим більше, якщо вони повторюються кілька разів, оскільки інструмент запропонує вам кілька варіантів перекладу за замовчуванням для нових міток ).

Підсумовуючи це: обґрунтоване дублювання та об'єднання міток у контекстний спосіб справді допомагає перекладачам виконувати свою роботу. Великий час. Подумайте лише про те: наявність контексту допомагає перекладачеві вибрати правильний переклад. І дозволяючи "виправдані" дублікати, виключається конфлікт необхідності вибору одного перекладу, який погано відповідає деяким контекстам (але найкраще підходить як би то не було).

Я сподіваюся, що це допомагає!

Коли я це робив у минулому, ми пішли маршрутом файлу ресурсів, що містить повні пропозиції. Якби точно те саме речення було використано неодноразово чудово, але якби це були лише окремі слова зсередини речення, то ці слова дублювалися б.

Ми були прив’язані до структури, де файл ресурсу просто містив перелік англійських фраз, за ​​якими слідує переклад (з деякими даними індексації в кінці для швидкого пошуку).

Для невеликих підказок або кнопок даних, таких як назва поля "Поштовий індекс" або кнопка "ОК", він зберігатиме рядок "Поштовий індекс", який слід за перекладом, і використовуватиме його там, де потрібна повна рядок. Але (якщо ми вручну не порушили рядок), він не використовував би його для "Поштового коду", який відображається у реченні.

Використовуючи приклад свого поштового індексу, якщо ви спробуєте і перекладете це самостійно і заміните його у всіх пропозиціях, які його використовують, ви отримаєте дуже поганий переклад.

Наприклад, "Поштовий індекс повинен бути введений", можливо, буде потрібно перекласти буквальний еквівалент "Введений поштовий індекс повинен бути" іншою мовою. Якщо ви складете речення, ви не зможете змінити потрібні слова іншою мовою.

Ось чому деякі погано зроблені переклади на англійську виглядають настільки смішними, що людина, яка це робила, просто перекладала окремі слова, а не ціле речення.

Ми завжди знаходили найкраще перекладати речення в цілому, не розбиваючи їх. У нас були власники місць для даних, які потребували вставки (наприклад, "Номер деталі @ 1 є зайвим"), і перекладач може перемістити власника місць у потрібне місце для гарного перекладу.

Однак ми виявили, що дозволяти місцям, які використовують саме те саме речення, те саме запит даних або однакову мітку кнопок тощо, було нормально ділитися перекладами. Це ніколи не підходило до проблеми та економило час / витрати для перекладача.

Ваше мислення щодо називання добре.

Цілі

• Визначте загальну мітку (тобто назву змінної) для локалізованого тексту.
• Етикетка повинна бути "розміром з розумом". Це ... як короткий практичний, але однозначний.
• Етикетки повинні дотримуватися послідовного формату, щоб максимально передбачити та нагадати.

Впровадження

• Зменшіть когнітивне навантаження за допомогою послідовного використання добре відомих скорочень (наприклад, msg = повідомлення, lbl = мітка, btn = кнопка, ...)
• Інструменти представляють змінні / мітки в алфавітному списку, тому пошук людей найкраще, коли споріднені мітки групуються разом. Зробіть імена ієрархічними від найбільш загальних до найбільш конкретних. (тобто msgFileMissing, msgFileSaved, msgFileDeleted).
• Англійська мова є впорядкованою мовою дієслова. Багато (більшість?) Інших мов є іменниковими. Іменник-дієслово найкраще працює для ієрархічного групування.