Реалізувати переклад в додатках Delphi можна реалізувати декількома способами:
- стандартний спосіб локалізації.
- локалізація за допомогою текстових ресурсів: ini-файл або xml-файл.
Стандартний спосіб локалізації додатків
За допомогою ресурсів потрібною мовою (за допомогою меню Project -> Languages). Цей спосіб часто описується в книгах по Delphi, а так само у великій кількості статей в інтернеті. Тому, цей спосіб не будемо описувати в цій статті.
Цей спосіб має як переваги, так і недоліки.
До переваг, можна віднести: швидкість роботи даної реалізації, а так само те, що цей спосіб реалізований в самому Delphi.
- Потрібно переводити прямо в середовищі розробки Delphi.
- За замовчуванням, витягується ресурс, тієї мови, якою встановлено в Windows.
Локалізація за допомогою текстових ресурсів
На жаль, локалізація за допомогою текстових ресурсів в Delphi не передбачена. Хоча, іноді цей спосіб може бути кращим, ніж переклад з допомогою ресурсів, реалізований в Delphi.
До переваг цього способу можна віднести:
До недоліків даного способу можна віднести:
- Меншу швидкість роботи, ніж через ресурси.
- Чи не реалізований даний спосіб в стандартному постачанні Delphi.
- Більший розмір файлу, ніж ресурсного файлу.
У текстовий формат можна зберігати у вигляді: ini-файлу, xml-файлу або текст із заданими роздільниками.
Є компоненти, які реалізують подібну задачу, але частіше за все, ці компоненти платні.
У даній статті ми опишемо спосіб локалізації в форматі xml.
Локалізація за допомогою xml-файлів
Перш за все, потрібно визначитися з тим, що ми переводимо.
Ми переводимо:
- строкові ресурси;
- варіантні типи;
- символьні типи;
Всі інші типи даних ми не переводимо.
Процес перекладу можна розділити на 2 етапи:
1-й етап. Генерація текстового файлу для подальшого переказу. Збереження його. Переклад. Перенесення в каталог відповідної мови.
2-й етап. Завантаження в додаток з xml-файлу.
Генерація текстового файлу для подальшого переказу
Для того, щоб згенерувати файл для перекладу нам необхідно перебрати всі компоненти і все властивості, сформувати текстовий файл.
Необхідно враховувати, що на формі можуть перебувати не тільки компоненти, але і фрейми, які самі в себе включають інші компоненти.
Так само можуть бути компоненти, які ми не хочемо переводити. Їх потрібно виключити з перекладу. Так, наприклад, не бажано переводити TDBEdit, TDBDateTimeEditE, TDBLookupComboboxEh, тому що нам не потрібно переводити інформацію, взяту з бази даних.
Нижче, наводимо функцію, яка формує xml-файл для перекладу.
Функція для формування xml для заданої компоненти:
Функція для формування xml для заданого властивості:
Функції, які використовуються в даному коді:
Завантаження в додаток з xml-файлу
Нам необхідно завантажити текстовий файл, декодувати інформацію в ньому і встановити властивості.
Отже, процедура декодування текстового файлу:
Отримання тексту між тегами:
Збереження і завантаження перекладу
Маючи описані вище процедури і функції ми легко можемо реалізувати збереження і завантаження інформації.
Файли для різних мов ми записуємо в різні каталоги, тому реалізуємо функцію для видачі шляху до файлу перекладу:
У даній функції:
- User_Sets.LangInterface - назва поточного мови. Замість цієї змінної поставте свій.
- NormalDir - нормалізує каталог. Ця функція була взята з JVCL. Можна обійтися і без цієї функції.
Формування файлу для перекладу:
Переклад змінних, констант
Від констант доведеться відмовитися.
Прямуємо традиції і реалізуємо переклад за допомогою xml. Для цього використовуємо TXMLCollectionItem і TXMLCollection.
Елементи перекладу (TXMLCollectionItem):
Колекція елементів перекладу (TXMLCollection):
Процедура для переведення всіх ресурсів:
демонстраційний проект
Вихідні тексти демонстраційного проекту:
Translate.zip (ZIP, 59Kb)
Скомпільований демонстраційний проект:
Translate-exe.zip