Wybór języka w aplikacji webowej

0

Zastanawiam się jak ugryźć temat wyboru języka w aplikacji webowej i routingu dla różnych wersji językowych aplikacji.

  • Czy tworzyć oddzielne widoki dla różnych wersji językowych?
  • Czy tworzyć słowniki tekstowe i ładowanie ich w komponencie w zależności od wybranego języka?
  • Jakieś inne rozwiązania?

Jak Wy to robicie?

0
baroo napisał(a):

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/localization?view=aspnetcore-5.0

Dzięki, to właściwie rozwiązuje mój problem. Nie powiem, nie spodziewałem się rozwiązania frameworkowego.

0

IMO znacznie latwiej zarządzac tlumaczeniami jesli sa w bazie danych albo w plikach, ktore nie sa kompilowane.
Do starego mvc są jakieś nugety z gotowymi rozwiązaniami. Poszukaj nugetów z i18n

0
jacek.placek napisał(a):

IMO znacznie latwiej zarządzac tlumaczeniami jesli sa w bazie danych albo w plikach, ktore nie sa kompilowane.

Wszystko zależy od tego, kto ma tymi tłumaczeniami zarządzać. Jeśli nie dotyczą stałych elementów GUI, to nie ma sensu zaprzęgać do tego bazy danych.
Nie ma też sensu wynajdować koła na nowo.

0

Jeśli nie dotyczą stałych elementów GUI, to nie ma sensu "

somekind napisał(a):

Wszystko zależy od tego, kto ma tymi tłumaczeniami zarządzać. Jeśli nie dotyczą stałych elementów GUI, to nie ma sensu zaprzęgać do tego bazy danych.

Jeśli dotyczą stałych elemementów UI to nie ma sensu. ^^^

Ja mam takie doświadczenia że warto jednak mieć taką elastyczność ale na pewno w tym jest duży udział specyfiki mojego stylu pracy, projektu, metod współpracy z klientem i jego decyzji.
Zastosowanie ReourceProvidera, który gada z bazą danych a poza tym nie różni się niczym od standardowego to nie jest wynajdywanie kola na nowo.

Głownie chciałem dodać, że istnieje taka możliwość.

0

Jeśli nie dotyczą stałych elementów GUI, to nie ma sensu zaprzęgać do tego bazy danych.

Właściwie to słownik ma obejmować głównie widoki (GUI) i DataAnnotations, może też coś jeszcze. I się zastanawiam czemu akurat wtedy miałby być zassany z DB? A później jak rozumiem trzymany w cache? A czemu nie z pliku? Czy chodzi o czas dostępu?

0

@somekind owi chodzi głównie o to, że EF to ch***wy ORM :) Taki żart. Wiem, wiem...

A poważnie, to raczej pomyłka.

Mi nie chodzi o czas dostępu tylko, IMO, o wygodę np. przy zmianach. Typowo tłumaczenia masz w Resourceach i każda zmiana wymaga przekompilowania i wdrożenia nowej wersji dll-a z resourcami. Podobnie dodanie nowego języka ale raczej kolejne języki dodajemy rzadko.
Ja nie robię osobnych widoków dla języków (zwykle, czasem robię jak w widoku jest dużo statycznego tekstu) tylko w jednym widoku dla wszystkich języków używasz "etykiet" zamiast jakichś stringów (np. App.Resource.UserName, App.Resource.Password). To jest tłumaczone przez na odpowiedni język standardowym mechanizmem ("Nazwa użytkownika", "Hasło" lub "Login", "Password").

Ja mam np. teraz w aplikacji 5 języków. Nie robię tłumaczeń. Ktoś to robi z tych krajów, mając dostęp do jakichś mechanizmów wspomagających tłumaczenia.

0

Nic o EF nie pisałem.
Po co zaprzęgać bazę danych tylko do tłumaczeń?

0

Nie tylko do tłumaczeń tylko zamiast dll z zasobami.

1 użytkowników online, w tym zalogowanych: 0, gości: 1