Сохранение текстов на разных языках в базе данных
По предлагаемой схеме тебе надо будет писать два разных метода получения текста - один для оригинального, другой для перевода.
нет никакого "оригинального", если вы его искусственно не создали. просто текст-ключ. например, "жопа". выдаем запрос таблице text получить id слова жопа, таблице language - запрос на id языка XY, и уже с этими двумя идями обращаемся в таблицу translate за текстом "жопа" на нужном языке.
При этом язык оригинального текста - неопределен.
что такое "оригинальный текст"?
Ворос тут скорее в том, где хранить информацию об языке - вместе с текстом или делать отдельный маппер...
ну да, это - самый главный вопрос... подумайте, как решить, может, что придумаете ...
Текущая культура в Дотнете хранится в CultureInfo.
откуда появился дотнет и прочее? кто сказал, что здесь вообще присутствует дотнет или иное? вопрос: как сохранить тексты на разных языках в базе данных. "остальное - от лукавого" (с)
просто текст-ключ.
-----
Заметь - это не Я написал.
При этом Я как-то не увидел на каком языке текст...
обращаемся в таблицу translate
-----
Что именно требует обращаться в эту таблицу?
Каков будет результат для заданого исходного с языком "русский"?
что такое "оригинальный текст"?
-----
Нннннну скажем что это текст для которого нет информации об языке.
подумайте, как решить
-----
Пару варианнннтов Я когда-то делал...
Тексты сохранить в отношении много ко многим в таблице связей. А дотнет - просто как пример, откуда возьмётся дефолтная культура. Неважно, дотнет или нет - всё равно выбор текущего языка неплохо бы поместить в настройки аккаунта.
Не понятно, что вам непонятно. Весь текст, включая интерфейс, или лишь его куски, требующие перевода, подставляются в виде переменных, в которых оказывается перевод согласно выбранной локали.
Я последние свои проекты - пару сайтов и WPF-приложение - сделал все с поддержкой локализации. И сейчас игру на Юнити делаю по тому же шаблону. Только я не в БД всё запихал, а в словари ресурсов, но суть от этого не меняется.
Всплыл недостаток сохранения локализованных данных в файлах resx. resx генерит в выходную директорию папки с названиями локалей и в каждой DLL с одним и тем же именем. Если я хочу импортировать эти DLL в, скажем, Юнити, то возникает ошибка - туда можно импортировать только одну DLL с тем же именем, при этом неважно, что они в разных директориях находятся. Придётся либо отказаться от хранения локалей, как это требуется для resx, либо придумать своё хранилище.
Самый простой вариант обойти это - отказаться от схемы "отдельный файл на локаль" и встроить обозначение локали в имя ресурса - типа "PersonName_en_US". А вытаскиваться ресурс через символы подстановки - типа
resourceManager.GetString($"PersonName_{locale}");
Но если ресурсы уже сохранены с прежней схемой, то куча работы по переписыванию - ручному или программному. Ну и теперь ломается схема работы с локалями самого класса ResourceManager.
Ещё как вариант - создать по сборке на каждую локаль и передавать в конструктор ResourceManager сборку текущей выбранной локали. Проблема только в том, что придётся отдельный проект для каждой такой локали делать, чтобы каждый проект свою DLL выпускал.
В МСДНе везде про resx файлы говорится и класс ResourceManager
Globalize and localize .NET applications | Microsoft Docs
Если есть способ заставить это всё дело сохранять локализованные ресурсы в DLL с разными названиями или в одну DLL, то для Юнити пойдёт. Нет - нужно искать другой подход. В Дотнете локализованные ресурсы сохраняются в либы с одним и тем же названием, но в разных папках.
С одной стороны вы говорите, что нужно быстро решать задачи. С другой - на каждый вопрос предлагаете максимально глубокое и долгое изучение, вместо ответа на конкретный вопрос. Если, конечно, вы знаете ответ.
Я импортирую в Юнити ДЛЛки. Юнити пишет, что не должно быть ДЛЛек с одним именем, неважно, как они раскиданы по директориям - Юнити нашёл в разных директориях одинаковые по имени ДЛЛки и не даёт их импортировать. Всё. Диапазон решений - либо одна ДЛЛ, либо много с разными именами, либо вообще другой подход, типа текстовых файлов (txt, xml, json, etc.).
...изучение...
-----
Для твоей же пользы - у тебя один из пробелов в навыках - работа с документацией. Просто не умеешь быстро находить нужное.
Вот Я тебя и отсылаю к документации - читать, разбираться и получать навык эффективной работы с доками.
Ты либо научишься учится, либо будет как сейчас.
А задачи - задачи надо решать быстро.
А для возможности решать быстро - надо дохрена и больше знать.
Ну а чтобы знать - надо ... учится. Много и постоянно.
Тут - без вариантов.
Не дает их импортировать
-----
А должен?
Читай доку на предмет типов ресурсов.
Потом будешь изучать как управлять (если стандарта не хватит) загрузкой и что надо для связывания ресов.
ответ дайте.
-----
А если не дадут то и решения не будет?
А всего-то - надо изучить организацию и использование ресурсов.
И, кстати, ресурс - американский... в основном... а для американцев не существует проблемы локализации в виду отсутствия не-американского языка... 
А если не дадут то и решения не будет?
А всего-то - надо изучить организацию и использование ресурсов.
И, кстати, ресурс - американский... в основном... а для американцев не существует проблемы локализации в виду отсутствия не-американского языка...
Если ответа не будет, то придётся самому изучать или что-то своё лепить. Но ответ всё это дело ускорит.
Всё они локализуют. Локализации нет в игрушках в Стиме, в магазинах приложений, или в нормальных программах, типа того же Фотошопа?
Не вопрос - не будет задачи, не буду локализовать. У меня на прежних работах никто не требовал локализации - достаточно было русского. Я сам на сайте и потом в WPF себе прикрутил. А с Юнити старый простой подход по МСДНовскому букварю не сработал - нужны танцы с бубном и копошения в кишках, как там эти ресурсы хранятся-деплоятся-обрабатываются.
достаточно было русского.
-----
А америкосам - достаточно американской версии английского.
И то, что в мире есть другие языки для многих мамерикосов - тайна за семью печатями.
Вот простой пример.
Винда 7. Обычные региональные настройки.
Мне нужны одновременно - американская клава, русская клава и... формат даты dd/mm/yyyy.
или что-то свое лепить.
-----
Флаг тебе в руки, барабан на шею и вперед, возглавлять колонну уволенных изобретателей лисапедов...
Прочитал тут всё
Create satellite assemblies for .NET apps | Microsoft Docs
Package and deploy resources in .NET Apps | Microsoft Docs
Resources in .NET apps | Microsoft Docs
Херня и вода - для моего вопроса ответа не дают. Единственный намёк - затолкать эти сборки-сателлиты (как раз те, что содержат сокмиленные ресурсы для локали) в глобальный кеш сборок, но там могут быть проблемы с доступом из Юнити. Да и на разных системах это в разных местах находится - Винда, Андроид и прочее. В моём случае лучше, когда всё в папке приложения лежит.
Сейчас видится такое решение - создать по проекту для каждой локали, дать сборкам разные имена (например, поместить в название имя локали), чтобы Юнити не ругался при импорте, загружать при старте приложения ту сборку, чья локаль выбрана.