Почему бы не использовать API-интерфейсы перевода вместо подхода с использованием пакета ресурсов?
Я знаю, что когда вы заранее знаете, что ваш продукт будет использоваться в этих конкретных странах, тогда люди должны использовать подход, основанный на использовании ресурсов. Но если мы не рассчитываем на то, во скольких странах наш продукт может быть запущен в будущем в настоящее время, то почему бы не перейти на API-интерфейсы перевода, подобные Google? Скажем, если мы планируем запустить наш продукт в новой стране, то при подходе с пакетами ресурсов вы должны сделать записи для каждой метки в текстовом файле. Но с этим подходом к переводу мы можем сделать файлы через apis перевода в начале сервера, чтобы сохранить перевод времени рун. Хотя я не видел ни одного проекта, делающего это на данный момент. Есть мысли по этому поводу?
3 ответа
Одна из главных причин не использовать автоматический перевод - это качество - вы не хотите только "переводить" свое приложение, вы действительно хотите " локализовать" его.
И даже если вы просто хотите перевести его, вы хотите, чтобы результат имел какое-то значение, которое требует контекста - в противном случае вы получите элементы меню / пользовательского интерфейса, которые имеют такие странные тексты, что пользователи будут думать, что ваша система настолько дрянная, что они Перестанем пользоваться переведенной версией или, что еще хуже, системой в целом.
Интерфейсы API перевода, хотя и полезны, не могут предоставить вам контекст в приложении, если это можно сделать как "сгенерированный человеком" контент в ресурсных пакетах.
Одна из веских причин не использовать API Google Transliteration состоит в том, что он устарел. Использование устаревшего API в новом проекте не кажется мне особенно мудрым шагом.