задний план
Недавно я получил бизнес-запрос на зарубежный проект. Проект в конечном итоге будет использоваться клиентами из разных стран. Ожидается, что клиенты будут иметь хороший пользовательский опыт. Поэтому внешний интерфейс необходимо адаптировать к интернационализации.
проблемы
На первый взгляд в нуждах этого заокеанского проекта нет ничего особенного, и кажется, что есть дополнительная международная адаптация. Но если хорошенько подумать, все оказывается не так просто, и фронтенд-разработка сталкивается со множеством новых проблем. Давайте разберем проблемы, с которыми обычно сталкиваются в международном развитии:
-
Копия страницы настраивается Существует примерно четыре типа копирования, которые необходимо настроить: метка, заполнитель, информация о подсказке проверки поля и гиперссылка.
-
стиль копирования страницы Особое внимание следует уделить стилю написания текстов, текст на разных языках может иметь разное исполнение. Например, как показано на следующих двух рисунках:
- Английский (стиль страницы обычный)
- Русский (необычный стиль страницы)
- Английский (стиль страницы обычный)
-
Дата, обработка числового формата Место, где на странице отображается дата или количество, также необходимо интернационализировать.
-
LTR/RTL Языковые привычки многих стран Ближнего Востока - это RTL, которые можно решить, используя направление и трансформацию.
-
Интернационализация изображения (баннера) Если вы хотите, чтобы интернационализация была достаточно качественной, необходимо также учитывать интернационализацию изображений.
-
Сторонние компоненты пользовательского интерфейса Если используются сторонние компоненты пользовательского интерфейса, такие как: elementUI, пользовательский интерфейс ant design и т. д., эти UI-фреймворки обычно утверждают, что поддерживают интернационализацию, но количество поддерживаемых интернационализированных языков ограничено, что может не соответствовать потребностям бизнеса.
-
Рабочая нагрузка на фронтенд-разработку и затраты на последующее обслуживание растут Необходимо извлечь много копирайта, и извлеченный копирайтинг в конечном итоге будет объединен в файл, например: en-US.json. Если эти задачи выполняются вручную, объем работы будет огромным.
Как быть с международным копирайтингом
Выше перечислено много проблем, но на самом деле «обработка копирования страниц» является основным противоречием, потому что это напрямую приводит к всплеску нагрузки на фронтенд-разработку и затратам на обслуживание. Далее остановимся на идее обработки копирайтинга.По сути, с точки зрения интернационализации jQuery, Vue, React и т. д. являются лишь носителями, а идеи реализации у всех одинаковые.Поэтому интернационализированная обработка копирайтинга не в сочетании с конкретной технической базой. Далее будет несколько идей по работе с международным копирайтингом.Каждая идея имеет высокие и низкие требования к продуктивности и производственным отношениям.Давайте временно будем соответствовать каменному веку,бронзовому веку и золотому веку.
каменный век
Традиционный международный процесс разработки: когда фронтенд-разработка достигает определенной стадии, копирайтинг извлекается в файл ресурсов (обычно en-US.json), а затем файл ресурсов отправляется команде переводчиков, а команда переводчиков переводит копирайтинг на разные языки.Язык соответствует файлу ресурсов, и, наконец, эти файлы ресурсов отправляются обратно разработчикам интерфейса, и разработчики интерфейса обновляются до своего собственного локального. Как показано ниже:
-
Применимая сцена
- Не так много копий для извлечения на странице
- Поддерживается меньше интернационализированных языков, например: требуется поддержка только китайского и английского языков.
- Требования к проекту относительно фиксированы, и на более позднем этапе будет выполняться только простое обслуживание, и никаких дополнительных требований добавляться не будет.
-
анализировать Это базовый процесс международного развития.«Предварительная разработка» и «команда переводчиков» — два незаменимых узла, но они слишком зависят друг от друга. Процесс «извлечения копии» по существу повторяющийся, поэтому его можно считать выполненным программой.
-
пример кода
- App.js
import React, { Component } from 'react'; import { IntlProvider, FormattedMessage } from 'react-intl'; import qs from 'querystring'; import logo from './logo.svg'; import './App.css'; import DEFAULT_MESSAGES from './i18n/en-US.json'; const DEFAULT_LOCALE = 'en-US'; class App extends Component { state = { messages: DEFAULT_MESSAGES, }; componentWillMount() { const search = window.location.search.slice(1); const params = qs.parse(search); const locale = params.locale || DEFAULT_LOCALE; const messages = require(`./i18n/${locale}.json`); debugger; this.setState({ messages, }); } render() { const { messages } = this.state; return ( <IntlProvider locale="en" messages={messages}> <div className="App"> <header className="App-header"> <img src={logo} className="App-logo" alt="logo" /> <p> <FormattedMessage id="welcome" defaultMessage={`Hello world!`} /> </p> <a className="App-link" href="/?locale=zh-CN" rel="noopener noreferrer" > zh-CN </a> <a className="App-link" href="/?locale=en-US" rel="noopener noreferrer" > en-US </a> </header> </div> </IntlProvider> ); } } export default App;
- en-US.json
{ "welcome": "Hello world!" }
Бронзовый век
В предыдущем анализе процесс «извлечения копии» по сути является повторяющейся работой, поэтому давайте посмотрим, есть ли способ его улучшить. Мы можем сначала сравнить процесс разработки интерфейса, когда нет «требований интернационализации» и «требований интернационализации». как показано на рисунке:
Видно, что справа есть еще три процесса:
- Извлечь копию как переменную
- Назовите переменную в соответствии с ее контекстом.
- Сохранение переменных и копирование информации в файлы ресурсов
Здесь мы выдвигаем ожидание или видение: мы надеемся развивать бизнес с международными потребностями так же, как развивать обычный бизнес!
Для достижения этого видения нам нужен инструмент: он может сканировать указанный файл и может идентифицировать строки в файле, а затем может генерировать имена переменных в соответствии со значением строк и заменять исходные строки переменными выражениями. , и, наконец, извлеченные переменные могут быть автоматически добавлены в файл ресурсов.
Как реализовать такой инструмент? Мы можем использовать Babel для анализа файла js в синтаксическом дереве, затем пройти и найти узел строки, затем вызвать Google Cloud Translation API для перевода строки на английский язык и использовать его в качестве имени переменной для получения выражения переменной, и наконец, используйте Переменное выражение заменяет исходный текст. Как показано ниже:
К счастью,i18n-pickОн уже такой на вкус~
- анализировать Это метод улучшения опыта фронтенд-разработки и повышения эффективности разработки на уровне разработки.Оставьте повторяющиеся действия программе для завершения.
Золотой век
Имея в качестве предзнаменования методы производства каменного века, мы можем продолжать совершенствоваться на этой основе. Поскольку между «front-end разработкой» и «командой переводчиков» слишком большая зависимость, мы можем добавить узел «платформа конфигурации копирайтинга» посередине. Внешний интерфейс напрямую загружает извлеченную копию на «платформу конфигурации для копирования», группа переводчиков напрямую переводит копию на «платформу конфигурации для копирования», а внешний интерфейс напрямую получает последнюю переведенную копию из « Платформа конфигурации для копирования».
- Основные возможности, которыми должна обладать платформа настройки копирайтинга
- Для фронтенд-разработчиков: копирование ввода и вывода
- Для команд переводчиков: копирайтинг, перевод, издательство
- Другое: Копирайтинг, контроль версий
- Применимая сцена
- Существует большое количество потребностей международного бизнеса
- Есть надежда, что он станет общей платформой для повышения эффективности развития бизнеса.
- анализировать Это сделано для оптимизации и улучшения международного метода разработки на архитектурном уровне.Как правило, крупные интернет-компании уже накопили много платформ с общими возможностями из-за сложности собственного бизнеса.
Суммировать
Каждая из приведенных выше идей имеет свои собственные применимые сценарии.В реальном производстве необходимо учитывать несколько аспектов, таких как стоимость разработки, опыт разработки, последующее техническое обслуживание и снижение производительности. Эта статья направлена на то, чтобы открыть идеи, бросая кирпичи и привлекая нефрит, и вы можете подбрасывать свои собственные идеи и обсуждать их вместе.
Ссылаться на
- Internationalization
- Интернационализация — универсальное решение для компоновки LTR/RTL
- i18n-pick
- Руководство по разработке плагинов Babel
- Google Cloud Translation API: Node.js Client
Статья может быть воспроизведена по желанию, но просьба сохранитьОригинальная ссылка.
Добро пожаловать!ES2049 Studio, отправьте свое резюме на caijun.hcj(at)alibaba-inc.com.