1. Обращение к UI элементам (Text, Image и т.д. ) - это довольно затратный метод. Менять кучу текстовых объектов в апдейте просто ради смены языка - это бессмысленная трата ресурсов. Сотня-другая таких объектов и одна только смена языка будет отжирать 25-50% производительности.
Решений тут два: первое и самое простое - вызывать проверку языка только один раз при старте сцены. При смене языка сцену нужно будет перезапустить.
Второй вариант - подписать метод смены языка на определенное событие через корутины. Проверка смены языка будет вызываться лишь один раз, при нажатии на определенную кнопку. Смысла в этом особого нету - лишний код ради функции, которую игрок за всю игру активирует единожды.
Поэтому оптимально будет сделать данный функционал только в главном меню. Если так уж нужна смена языка "на горячую" и без перезапуска, то лучше привязать элементы главного меню именно к нажатию кнопки, но никак не плодить кучу Update() там, где это не нужно.
2. Сам метод работы с локализацией удобоварим, если у тебя текста на пару десятков объектов. В ином случае, ты замучаешься работать с таким объемом окошек и объектов. Лучший метод для работы с текстом - вешать в скрипт объекта только его ID. В объекте должен быть только персональный ключ и всё. А весь остальной функционал нужно вызывать из некого синглтона, в котором и находятся все методы для работы с текстом.
То есть, ровно так же, как ты создал статическую переменную со значением текущего языка, ты создаешь целый статический класс, с методами и текстовыми массивами. В эти методы и обращается твой текстовый объект при старте. Он отсылает свой ID и получает по нему текст, который к себе применит.
Это обязательно нужно делать, потому что текстовых файлов у тебя может быть тысячи и при смене методов работы с локализацией, тебе нужно будет перенастроить их ВСЕ. Поэтому их функционал не должен содержать никаких уникальных данных, кроме одного - ключа, ID, который определяет, что именно это за слово или текст. А вот синглтон у тебя один. И менять его ты можешь как и сколько хочешь, без ущерба для своих объектов.
3. Сами текстовые данные лучше хранить в отдельном текстовом файле. Какая там будет верстка и формат - вопрос открытый. Кому-то гугл-таблицы нравятся, а кому-то html-формат - самое оно. Но это актуально, если у тебя объем текста выше 30 слов и далеко не пара языков на выбор.
Пока что это видео про то, как делать нельзя ни в коем случае.
exooman, спасибо за развернутый ответ и критику! Такие комментарии приятно читать, даже если Вы пишите, что то что я сделал не совсем верно. И я сам понимаю, что там далеко все не идеально. Я постараюсь в дальнейшем не допускать таких ошибок. Еще раз спасибо.
В точку сам так делаю. Кроме пункта 3 потому что у меня всего два языка и текстов пока не супер много. Обычные двумерные массивы в классах выводящих в интерфейсы. Как правило один класс на сцену. Они берут индекс выбранного языка из статического класса прикрепленного к объекту который не уничтожается при загрузках. Смена осуществляется в главном меню. Носитель создается в 0 сцене.
1. Обращение к UI элементам (Text, Image и т.д. ) - это довольно затратный метод. Менять кучу текстовых объектов в апдейте просто ради смены языка - это бессмысленная трата ресурсов. Сотня-другая таких объектов и одна только смена языка будет отжирать 25-50% производительности.
Решений тут два: первое и самое простое - вызывать проверку языка только один раз при старте сцены. При смене языка сцену нужно будет перезапустить.
Второй вариант - подписать метод смены языка на определенное событие через корутины. Проверка смены языка будет вызываться лишь один раз, при нажатии на определенную кнопку. Смысла в этом особого нету - лишний код ради функции, которую игрок за всю игру активирует единожды.
Поэтому оптимально будет сделать данный функционал только в главном меню. Если так уж нужна смена языка "на горячую" и без перезапуска, то лучше привязать элементы главного меню именно к нажатию кнопки, но никак не плодить кучу Update() там, где это не нужно.
2. Сам метод работы с локализацией удобоварим, если у тебя текста на пару десятков объектов. В ином случае, ты замучаешься работать с таким объемом окошек и объектов. Лучший метод для работы с текстом - вешать в скрипт объекта только его ID. В объекте должен быть только персональный ключ и всё. А весь остальной функционал нужно вызывать из некого синглтона, в котором и находятся все методы для работы с текстом.
То есть, ровно так же, как ты создал статическую переменную со значением текущего языка, ты создаешь целый статический класс, с методами и текстовыми массивами. В эти методы и обращается твой текстовый объект при старте. Он отсылает свой ID и получает по нему текст, который к себе применит.
Это обязательно нужно делать, потому что текстовых файлов у тебя может быть тысячи и при смене методов работы с локализацией, тебе нужно будет перенастроить их ВСЕ. Поэтому их функционал не должен содержать никаких уникальных данных, кроме одного - ключа, ID, который определяет, что именно это за слово или текст. А вот синглтон у тебя один. И менять его ты можешь как и сколько хочешь, без ущерба для своих объектов.
3. Сами текстовые данные лучше хранить в отдельном текстовом файле. Какая там будет верстка и формат - вопрос открытый. Кому-то гугл-таблицы нравятся, а кому-то html-формат - самое оно. Но это актуально, если у тебя объем текста выше 30 слов и далеко не пара языков на выбор.
Пока что это видео про то, как делать нельзя ни в коем случае.
exooman, спасибо за развернутый ответ и критику!
Такие комментарии приятно читать, даже если Вы пишите, что то что я сделал не совсем верно. И я сам понимаю, что там далеко все не идеально.
Я постараюсь в дальнейшем не допускать таких ошибок. Еще раз спасибо.
В точку сам так делаю. Кроме пункта 3 потому что у меня всего два языка и текстов пока не супер много. Обычные двумерные массивы в классах выводящих в интерфейсы. Как правило один класс на сцену. Они берут индекс выбранного языка из статического класса прикрепленного к объекту который не уничтожается при загрузках. Смена осуществляется в главном меню. Носитель создается в 0 сцене.