Лучшие практики для интернационализации веб-приложений?
Я вижу, что это старый пост, но я нашел его полезным и подумал, что поделился бы решением, аналогичным тому, что предложил @kzqai:
У меня есть функция, которая получает два параметра, такие как ...
function getTableInfo($inTableName, $inColumnName) {
....
}
Внутри я проверяю массивы, которые я установил, чтобы убедиться, что доступны только таблицы и столбцы с «блаженными» таблицами:
$allowed_tables_array = array('tblTheTable');
$allowed_columns_array['tblTheTable'] = array('the_col_to_check');
Затем проверка PHP перед работающий PDO выглядит как ...
if(in_array($inTableName, $allowed_tables_array) && in_array($inColumnName,$allowed_columns_array[$inTableName]))
{
$sql = "SELECT $inColumnName AS columnInfo
FROM $inTableName";
$stmt = $pdo->prepare($sql);
$stmt->execute();
$result = $stmt->fetchAll(PDO::FETCH_ASSOC);
}
3 ответа
Интернационализация трудна, вот несколько вещей, которые я узнал из работы с 2 веб-сайтами, которые были на более чем 20 различных языках:
- Использование UTF-8 везде. Никакие исключения. HTML, язык серверной стороны (не упускают PHP особенно), база данных, и т.д.
- Никакой текст в изображениях, если Вы не хотите тонну работы. Используйте CSS для помещения текста по изображениям при необходимости.
- Отдельная конфигурация от локализации. Тот путь localizers может перевести текст, и можно иметь дело с различными конфигурациями на локаль (функции, расположение, и т.д.). Вы не хотите, чтобы localizers имел способность смешать с Вашим приложением.
- Удостоверяются, что Ваши разметки могут иметь дело с текстом, который в 2-3 раза более длинен, чем английский язык. И также на 50% меньше, чем английский язык (японский язык и китайский язык часто короче).
- Некоторым языкам нужны большие размеры шрифта (японский язык, китайский язык)
- , Цвета являются определенными для локали также. Красный и зеленый не означают того же самого везде!
- Добавляют имя класса, которое является именем локали к тегу основного текста Ваших документов. Тем путем можно определить расположение определенной локали в файле CSS легко.
- Не упускают подстановку переменных. Не разделяйте свои строки. Оставьте их целыми как это: "Вы имеете X новых сообщений" и заменяете 'X' #.
- Различные языки имеют различную плюрализацию. 0, 1, 2-4, 5-7, с 7 бесконечностями. Трудно иметь дело с.
- Контекст является трудным. Иногда localizers должен знать, где/как строка используется, чтобы удостовериться, что это переводится правильно.
Ресурсы:
В моей компании все наши строки хранятся в *.properties файлах. Наши инструменты сборки создают "тест languange" копия файлов свойств, которые заменяют строку как это:
Click here
с чем-то вроде этого:
[~~ Çļïčк н∑ѓё ~~ ﾀｳ ~~]
Теперь, когда мы устанавливаем язык, чтобы "протестировать" в наших файлах конфигурации, эти файлы свойств используются. (И конечно мы не поставляем тестовые файлы языка).
Это позволяет нам:
- Удостоверяются, что символы Unicode отображены правильно, включая японский язык/Китайца/Корейца.
- Удостоверяются, что расположение масштабируется соответственно для языков с более длительными словами (немецкий язык в особенности имеет более длительные слова в среднем, чем английский язык).
- Пятно любые трудно кодированные строки (как они будут без обиняков).
Что касается фактического перевода, это сделано профессиональными переводчиками, не разработчиками.
У меня есть пара приложений, которые являются "двуязычными", я использовал файлы ресурсов у asp NET1.1
существует также что-то позвонившее Инструмент Строкового ресурса В основном, Вы помещаете все свои строки в.RES файл для обоих языков и затем определяете, какой файл читать из на основе Культуры или нажал ли кто-то на ссылку для языка
, самый большой глюк удостоверяется, что Переводы сделаны правильно