i18n - Legacy ASP.NET MVC, głownie zawartość bazy danych

Siemka
Nie wiem czy ten temat ie został już jakoś mądrze globalnie rozwiązany 100 lat temu, ale jak szperam googla to jakoś nie widzę. Są różne pomysły ale raczej specyficzne.

Potrzebuję dodać kilka języków do istniejącej aplikacji asp.net mvc. Sam interfejs nie stanowi dużego problemu, ale jest sobie baza (nie jakaś strasznie wielka) z produktami, opcjami, jakimiś innymi opisami i trzeba to przetłumaczyć (nazwy i jakieś opisy produktów, opcji, wartości opcji itp).

Szukam jakiegoś super mądrego pomysłu, który pozwoli nie zmieniać wszystkiego w szczególności tego co wychodzi z DAL. DAL jest na EF 6.

Kod nie jest jakiś szczególnie ładny a teraz na pewno całości nie przepiszemy. W dużej części jest oparta na Encja Na Twarz I Pchasz.

https://docs.microsoft.com/pl-pl/aspnet/core/fundamentals/localization?view=aspnetcore-2.1

Ta encja na twarz używa ViewModeli? Czy walisz persistence bezpośrednio do view ?

Podany link, po pobieżnym przejrzeniu, dotyczy chyba raczej interfejsu aplikacji.

Czasem używa ViewModeli a czasem nie używa. Od jakiegoś czasu to przepisuję przy okazji. W części dostępnej dla klientów (które muszą być lokalizowane) jest sporo ViewModeli i mogę chyba założyć, że ta część będzie możliwa do przepisania w całości. Da się to jakoś wydzielić może nie pod DDD bo nie ma na to teraz czasu i pieniędzy (i nie wiem czy miałoby to sens) ale jakieś normalniejsze serwisy. Możemy założyć, że będą ViewModele w całym zakresie lokalizowania.

Generalnie to jest app do składania zamówień. Są produkty, opcje, itp. I właśnie te produkty i opcje, które są w DB przez EF trzeba przetłumaczyć.

Rozumiem, ze idziesz w kierunku tabel z językami dla tabel typu Produkty, Opcje itp i wrzucania przetłumaczonych wartości w ViewModelu?

Dodaj te produkty i tp. do innych tabel z suffixem języka. np. "ProductPL" Przy zmianie języka zmieniasz DBContext w EF.

Nie "zrobisz DDD" w ten sposób. Najpierw byś musiał wywalić operacje krudowe za płot, czyli zrobić to na jednym serwisie.

Dzięki za odpowiedź.
Chyba zbyt proste to jest dla mnie. Produkty mają opcje i w przypadku osobnych tabel językowych i tworzenia innego DBContextu do językowych tabel podpiąć tabele z opcjami i inne do lokalizowanych tabel produktów. Dodatkowo tam jest straszny mechanizm ustalania poprawnych kombinacji opcji produktu i on bazuje mi. in. na Id produktu.

Zastanawiam się nad tabelami językowymi typu ProductTranslation (Produkt_id, Language, ProductName, Description itp) i powiązanie produktu ale nie wiem czy nie ma czegoś bardziej ogólnego.

Jeśli liczba języków jest stała, to możliwym rozwiązaniem jest zrobienie sobie jakiegoś ComplexType i użycie go zamiast zwykłego string dla tych właściwości, które mają być przetłumaczone. Jeśli przeciążysz w nim ToString tak, aby zwracał tłumaczenie wybrane na podstawie kultury wątku, to prawdopodobnie zadziała nawet w podejściu encja na twarz i bez ruszania obecnego GUI, zadziała też tam, gdzie już zwracasz jakieś viewmodele.

W sumie, to może i nawet z dowolną liczbą języków zadziała, jeśli zrobisz sobie jakąś brzydką serializację par kod języka: tekst wewnątrz tego complex typu.