Podejście do internacjonalizacji aplikacji

0

Jak podejść do projektowania aplikacji, która ma np. obsługiwać wiele języków?

Baza:

Każdy obsługiwany język swoja ma swoją bazę

  • Zaleta: 1 baza = 1 język, zatem unikamy mieszania wszystkiego razem i pól typu: text_PL, text_ENG, text_DE itd.

  • Zaleta: mniejsze obciążenie na instancje bazy

  • Wada: trzeba się męczyć z synchronizacją np. stałe podpięcie do kilku baz, aby dodając w text_PL od razu dodać przetłumaczony text do bazy w ENG.

  • Wada: trzeba się więcej bawić z backupami.

Wszystko w 1 bazie:

  • Zaleta: tworząc nową treść od razu wypełnialibyśmy wszystkie języki (łatwiej w porównaniu do poprzedniego podejścia)

  • Zaleta: łatwy backup

  • Wada: trochę burdel

Aplikacja:

Instancje czy jakieś redirecty np. na podstawie preferencji w cookie?

np. de.example.com przekierowuje na aplikację pod portem 5200, pl.example.com przekierowuje na 5202 itd.

  • Zaleta: mniejsze obciążenie na instancję

  • Wada: więcej zabawy z konfigurowaniem jakichś reverse proxy, zasobów, może load balancingu itd.

A może jakieś inne, ciekawsze pomysły? lub generalnie jak to u was wygląda :)

0

Pisząc baza masz na myśli baze SQL??

Bo generalnie kilka razy pracowałem z aplikacją, gdzie teksty były w bazach SQL i to zwykle było strasznie niewygodne. Jedyna zaleta to możliwość łatwej podmiany tłumaczeń w locie.
(ale kał związany z tym, że ktoś pozmieniał część tłumaczeń na produkcji, a drugą cześć na testach - jest nie do ogarnięcia).

My javowcy normalnie teksty trzymamy w plikach moduleName_de_CH.properties lub (to nie jest standard) module_de_CH.json.
Taki format jest łatwy do obróbki przez programy do tłumaczeń, pliki są wersjonowane w gicie. (I od biedy da się też zrobić podmianę tekstów bez restartu aplikacji).

0

@jarekr000000:

Raczej pliki odpadają, bo modele biznesowe opierają się na tych przetłumaczalnych rzeczach, więc dodawanie, edycja, usuwanie musi być w locie, a raczej nie chciałbym się bawić w zapis/odczyt z pliku :P

Powiedzmy coś jak artykuły w gazetach, które są ciągle pisane, poprawiane, usuwane itd. przez jakichś redaktorów. Z taką różnicą, że tutaj jest kilka języków.

0

"DevOps"???
Chcesz internacjolizować skrypty deplojujące?
Albo SQL?

Podaj język programowania, bo każdy z popularnych języków ma to rozwiązane, ale na swój specyficzny sposób.
Chyba że chcesz robić to niezależnie od aplikacji, co może być trudne, ale jest wykonalne:
https://en.wikipedia.org/wiki/Gettext

4
WeiXiao napisał(a):

Powiedzmy coś jak artykuły w gazetach, które są ciągle pisane, poprawiane, usuwane itd. przez jakichś redaktorów. Z taką różnicą, że tutaj jest kilka języków.

To nie jest internacjonalizacja aplikacji - tylko typowy przykład wielojęzycznego contentu.

Warto nawet te dwie rzeczy rozdzielić.
Czyli możesz mieć jako edytor treści angielską wersję aplikacji (angielskie menu) i edytować treść rosyjskiego artykułu.

1

Jeśli chodzi o content to najlepiej podoba mi się wersja z Wikipedii.
Jak trafisz z wyszukiwarki na wersję polską, to na niej lądujesz. Jak na angielską, zostajesz na angielskiej.
A z boku masz możliwość wybrania innej wersji językowej, która akurat jest i którą rozumiesz albo chcesz poznać.
Auto-przekierowanie mnie osobiście wkurza, nie wiem jak innych.

0
vpiotr napisał(a):

Jeśli chodzi o content to najlepiej podoba mi się wersja z Wikipedii.
Jak trafisz z wyszukiwarki na wersję polską, to na niej lądujesz. Jak na angielską, zostajesz na angielskiej.
A z boku masz możliwość wybrania innej wersji językowej, która akurat jest i którą rozumiesz albo chcesz poznać.
Auto-przekierowanie mnie osobiście wkurza, nie wiem jak innych.

No ok, ale pod spodem to jakoś tam działa, i o to mi się rozchodzi :P

Gdyby ktoś chciał, to coś tam wygrzebałem na ten temat (db)

http://www.vertabelo.com/blog/technical-articles/data-modeling-for-multiple-languages-how-to-design-a-localization-ready-system

2

W bazie trzymasz to normalnie jako osobne artykuły z opcjonalnymi linkami do siebie.
A czy to jest w jednej bazie, na jednym serwerze czy na 100 to zależy chyba głównie od stopnia rozproszenia bazy (sharding, NoSQL) a nie designu tabel. Ja tam przynajmniej bym tak wolał.

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