Эй, кто мне минусы лепит? Лучше ответ дайте. ))

А там ведь платно вроде бы, не? Если платно, то сомневаюсь что кто-то зареган из этого форума там. Ну это всегда так, сплошные хейтеры и тролли. Влепил кто-то дизлайк, и спрятался.

На SO платно? Не знаю, как сейчас, а 7-9 лет назад всё бесплатно было. Да и недавно на их других сайтах из Stackexchange регался - бесплатно.

Короче, в Юнити сделано всё так, чтобы максимально усложнить тебе жизнь при использовании чего-то не из Юнити. Поэтому ставишь тамошний плагин по локализации или покупаешь чего-то в ихнем магазине плагинов и не выё... Юнити, похоже, больше зарабатывает на продаже всяких штук в своём магазине для разработчиков, чем на просто лицензиях своего движка, поэтому всё, что стороннее и не из стора - максимально затруднено для интеграции.

Так как вы решили делать-то? Через таблицы связей между языковой таблицей и всеми остальными, где требуется перевод? Получилось как хотели или нет?

Так как вы решили делать-то?

Это было ка бы "научное исследование". До конкретной имплементации пока еще далеко.

Хорошего решения всё равно нет. Или медленно или неудобно

В самом универсальном решении всего одна таблица связей добавляется, и лишь для информации, которая требует локализации. По наблюдениям за другими сайтами, в том числе крупных компаний, некоторые предпочитают вообще разные версии сайтов для каждой локали держать. Лишь похожие элементы оформления и стилей используют. Ну это у кого денег и времени много.

В самом универсальном решении всего одна таблица связей добавляется,

Скорость не подсчитывали?

Неа. Предложенное решение - лучшее с точки зрения организации и дальнейшей поддержки. Для скорости лучше, наверное, завести в таблице столько вариантов одного поля, требующего локализации, сколько самих локалей предусмотрено. Тогда будет так же быстро, как и обычное обращение к таблице БД без локализации.

Для скорости лучше

-----

Ты бы по базам что-нибудь почитал, что ли...

Две таблицы

T1

id

name

T2

id

nameEn

nameRu

nameDe

Есть вариант сделать мультиязычность быстрее, чем во второй таблице?

Конечно есть! Причем - больше одного варианта.

Но чтобы понимать что надо делать - надо изучать базы чутка глубже, чем написание селектов...

И, можешь смеятся, надо будет освоить работу с файлами... в том числе - с большими (больше размера памяти) файлами... об чем тебе давалась элементарная задачка.

Тут что-то написали https://stackoverflow.com/questions/537204/localisation-i18n-of-database-data-in-linq-to-sql

Конечно есть! Причем - больше одного варианта.
Но чтобы понимать что надо делать - надо изучать базы чутка глубже, чем написание селектов...
И, можешь смеятся, надо будет освоить работу с файлами... в том числе - с большими (больше размера памяти) файлами... об чем тебе давалась элементарная задачка.

Размера какой памяти? БД и не держит все таблицы в оперативке. Или вам нужна локализация многих текстов размерами в гигабайты каждый?

А если задача не стоит делать всегда и обязательно рекордные БД (ну не все тут Гуглы или обрабатывают миллиарды записей), то таблицы связей и локализованные поля начинают работать? Ведь конкретное решение зависит от задачи:

1) вас устраивает тупой говнокод - даже с ним ничего не тормозит;

2) вас устраивает простое следование простым примерам из букварей;

3) вас устраивает просто хорошо написанная БД в стандартной СУБД;

4) вы делаете какие-то хаки-доработки для стандартной СУБД и экспериментируете со схемами БД;

5) вас уже не устраивает стандартная БД и хаки-доработки не помогают, вы делаете свою БД, заточенную под ваши задачи.

Ваши советы почти всегда из разряда не ниже 4. Тогда как подавляющее число задач решается способами 1-3.

И вы не могли бы почаще давать конкретные советы, как и что именно тут и здесь можно сделать, а не общие, типа почитай этот толмуд, пройди этот курс?

Есть вариант сделать мультиязычность быстрее, чем во второй таблице?

А зачем тут 2 таблицы :)

Я бы сделал так:

T_En

id

text

T_Ru

id

T_De

id

Собственно говоря, лет 15 тому назад мы так и сделали.

Логика менеджера была простая как мычание :

1) Взять строку из T_xx

2) Если строки нет, то взять строку из T_En

3) Если строки нет, то вернуть id

А для того, чтобы сразу было видно, прошла ли эта строка через менеджер, в дебаг моде к каждой строке добавлялся префикс '###'.

Все просто и понятно. При этом сразу видно какие строки берутся из БД, а какие хардкодед. И всегда можно легко найти строки без перевода.

А зачем тут 2 таблицы :)

Я привел пример двух таблиц - без локализации и с. И в какой будет производительность больше и насколько? В смысле, что так ли уж критично использовать какой-то особенный подход с изъё...вом в архитектуре или подключением обычных файлов с диска?

Я бы сделал так:

Имеет право на существование. Но. Добавлять новый язык будет не так просто. И если уж мы заботимся о скорости... Такое решение будет медленнее джойна с таблицей с локализованными текстами.

Потому что менеджер явно на стороне приложения. А значит на поиск перевода тратит новый запрос. А раундтрип у запроса раз в ... 10? больше стоимости джойна вроде

SELECT а.*, c.text as CITY_LOC FROM ADDRESS a JOIN I18_TEXT c ON a.CITY_NAME_ID = c.ID AND c.LANG = "en" WHERE ....

Я бы сделал так:

Вы просто храните все локализованные тексты в таблицах по одной на язык. А подключаете их как? Типа такого?

T_Item

id description - id from T_En

Как выбор таблицы с нужной локалью происходит?

НП.

Наверное нужно применять LINQ, там можно разную магию делать, насчёт СУБД в память, есть In Memory DB - https://docs.microsoft.com/ru-ru/sql/relational-databases/in-memory-database?view=sql-server-ver15

И вы не могли бы почаще давать конкретные советы

-----

Тебе снова сказать про фрагментированность твоих знаний?

Ни один, ни сотня конкретных ответов в этом плане ничего не поменяют, а только усугубят ситуацию.

почитай этот толмуд, пройди этот курс?

-----

А что делать, если ты сам не учишься? Учить-то за тебя никто не будет...

Похоже, что и тебя учить тоже никто не будет.

из разряда не ниже 4.

-----

Вообще-то - чистая 3.

Только чтобы это понять надо знать чутка больше чем написание селекта. Не на много, но все же больше.

лет 15 тому назад мы так и сделали

-----

Угу... А во что выльется добавление еще одного языка?

Я бы сделал так

-----

Ну а Я бы почитал про партиционирование...

По задаче - не вижу никаких преимуществ в куче дублирующих таблиц, тем более что базы, в большинстве своем, имеют встроенный механизм для разнесения данных аналогично предложенному.