Одна из зон ответственности моей [бывшей] команды в Лавке -- локализация (т.к. сервис существует в нескольких странах).
Там мы понимали под локализацией всё сразу, но вообще есть некоторое разделение:
- internationalization (i18n) -- техническая возможность работать с разными языками.
- localization (l10n) -- адаптация контента и дизайна под конкретный рынок. Это не только про перевод, но и про культуру (юмор, отсылки, визуал). Этим конечно не разработка занимается.
Иногда вы можете по качеству озвучки фильма сказать, был ли он локализован или просто переведён. Когда я услышал в очередном голливудском произведении «встречусь с бесконечно вечным», мысленно снял шляпу.
- globalization (g10n) -- это что-то бизнесовое про координацию усилий везде вкупе.
Технически наиболее интересным является i18n.
Фактически это про возможность корректно работать с переводами.
Когда в коде уже не используются строки, а только ключи, по которым переводы получаются из какого-то kv-хранилища.
Сюда же включаем направление письма (иврит, например, пишется right-to-left). Форматирование чисел (точка/запятая для дробных). Форматирование дат (порядок день/месяц/год в любой комбинации). Форматирование валют. Поддержка множественного числа объектов (1 собака, но 5 собак). Поддержка склонений.
По-хорошему вот это всё ваша библиотека должна уметь поддерживать.
Конечно, реализовать подобное == примерно поддержать инфру для задачи + разобрать миллион кейсов.
Переводить в идеале не кусками, а целыми предложениями/фразами:
чёрный кот на английском -- black cat
чёрный кот на испанском -- el gato negro
Переводить по слову получится грамматически неверно.
Аналогично про согласование различных слов. В русском/испанском/французском языках прилагательные могут меняться в зависимости от рода объекта, к которому они относятся. Тогда в идеале перевести всё заранее и никак не параметризировать строки. Будет меньше проблем.
Опыт ещё научил всегда сразу выносить переводы нормально. В идеале ещё и ключ не хардкодить, а вынести его в конфиг (чтобы в рантайме можно было поменять). Продакты бесконечно любят выяснять, как мельчайшие вещи, даже отдельные тексты, влияют на восприятие приложения, так что вы сэкономите себе время, если сразу сделаете нормально.
Кол-во раз, когда перевод хардкодили, а потом приходилось возвращаться и переделывать, даже неприлично озвучивать.
Если нужна либа для i18n под плюсы, можно взять icu4c. Я честно видел её в коммерческой разработке. Правда, мне не оч понравилось с ней работать.
Конечно, для поддержания нормального решения нужно слишком много. Всегда можно просто сходить по API в переводчик и получить ответ. Но может получиться что-то такое: