Интернационализация в базе данных
Это другие материалы, которые я нашел:
Пожалуйста, дайте пользователям знать, что использование «бесплатного» сервиса OneSignal позволит компании получать данные пользователей и продавать их другим.
Служба облачных сообщений Google Firebase является надежной, но стоит дорого, если вам нужно много подключений. См. Тарифные планы Firebase.
Я лично использовал fcm. Это был не очень простой способ реализовать его на моей диссертации, но он работал хорошо. Не нужно заставлять приложение прослушивать фоновые сообщения для входящих уведомлений, а затем создавать локальные уведомления, чтобы я не продавал данные моих пользователей и не платил ничего за использование услуг firebase. Я воспользовался бесплатным подарком в 300 долларов от облака Google, чтобы покрыть расходы из плана зажигания Firebase. (Бесплатно на 12 месяцев)
Предупреждение , если вы используете плагины Cordova от fcm: Если у вас есть плагин cordova, который использует службы Google, он может вступать в конфликт с плагинами fcm, перечисленными выше, из-за разных используемых версий. Может потребоваться ручное редактирование плагинов src.
Если вы решите использовать fcm, эта ссылка может вам помочь. Основные действия, которые вы должны выполнить после настройки необходимой среды, - это
- Получить токен FCM на платформе асинхронность платформы.
- Сохраните его в firebase под указанным пользователем
- Создайте облачную функцию, которая будет отправлять уведомления
6 ответов
Интернационализация расширяется на базу данных, поскольку Ваши столбцы смогут содержать данные. NText, NChar, NVarchar вместо текста, Символа, Varchar.
Насколько Ваш UI идет для неизменения маркировок, файлы ресурсов являются хорошим методом использовать.
Если Вы отсылаете к созданию Вашей поддержки приложений несколько языков на уровне UI, то существует больше возможностей. Если маркировки никогда не изменяются, если при выпуске новой версии то файлы ресурсов, которые встраиваются в исполняемый файл или сам блок, являются лучшим выбором, так как они работают быстрее. Если Ваши маркировки, с другой стороны, должны быть скорректированы во времени выполнения пользователями, то хранение переводов в базе данных является хорошим выбором. До самого кода, названий таблиц и полей в базе данных, мы сохраняем их на английском языке как можно больше, так как английский язык является "фактическим" стандартом для людей IT.
Это во многом зависит того, что Вы храните в своей базе данных. Взятие примеров из недавнего проекта, я шел, пленочный заголовок, который вводится в клиентский сайт и только видимый тому клиенту, является справедливой игрой для хранения как есть в базе данных. Код ошибки проектора, с другой стороны, потому что это может быть просмотрено клиентом, а также центрами эксплуатации сети, которые могли бы быть в разных странах, должен быть сохранен как код ошибки (и иллюстрирующие материалы, как часы лампы и заголовок показываемого фильма), который может быть переведен на gui уровне в зависимости от установки языка средства просмотра.
@hova покрывает технические особенности, но что-то, что Вы могли бы хотеть рассмотреть, является поддержкой системы, показывающей язык, который Вы не понимаете.
Один способ справиться с этим состоит в том, чтобы иметь английский язык как язык по умолчанию и пользователя, устанавливающего, который переключается на другой язык. Тем путем Ваши пользователи поддержки могут войти в систему и видеть систему естественным способом (принимающий английский язык как их первый язык), и Ваши фактические пользователи видят систему на своем первом языке. IMO, данные должны всегда быть 'естественными' - на языке пользователей.
Который поднимает другой интересный вопрос - Ваша система должна позволить несколько языков для международных установок? По моему опыту, для пользовательского интерфейса да, но для данных, нет. Для взятия тривиального примера форматирования адреса буква французскому третьему лицу от швейцарской системы должна все еще иметь адрес швейцарского формата вместо французского, поскольку это должно перейти швейцарскую почтовую систему сначала.
Если Ваши клиенты - японцы и хотят видеть свои имена в Kanji и Katakana (и иногда в самом формальном Gaiji), необходимо сохранить их как Unicode. Никакой путь вокруг этого.
Даже вещи как адреса очень отличаются между США и Японией. Одна схема не сократит его для обоих.