Budowanie bazy danych tłumaczeń ciągów dla wielu (wewnętrznych) projektów

W naszej firmie mamy istniejącą tabelę tłumaczeń ms-sql, która przechowuje takie ciągi:

Id |     Key     | Language | Value 
 1 | hello-world |  nl-BE   | Hallo Wereld
 2 | hello-world |  en-GB   | Hello World

System ma 3 języki i spodziewam się, że w przyszłości liczba ta wzrośnie do maksymalnie 10

Ta tabela jest odczytywana przez wiele bardzo różnych projektów (około 60 projektów, głównie stron internetowych / aplikacji internetowych i niektórych usług internetowych), z których każdy otwiera połączenie bazy danych z bazą tłumaczeń, buforuje tłumaczenia

Informacje zwrotne od deweloperów front-end są takie, że nasz interfejs użytkownika wprowadza lub modyfikuje największą wadę tłumaczeń, ponieważ nie mogą wiedzieć, który projekt używa jakich ciągów.

Czasami modyfikują ciągi, nie wiedząc, że zrywają z nim 7 projektów.

Teraz muszą po prostu wpisać coś podobnego, this.Translate("Hello World")a system zajmie się resztą.

Mógłbym oczywiście zmusić ich do czegoś takiego, this.Translate("Hello World","AwesomeApplication1")ale wydaje się, że będzie to wymagało sporo refaktoryzacji w wielu projektach.

Jak poszedłbyś na temat zapewnienia tego rozwiązania? W jaki sposób jako twórca podałbyś tłumaczenie nazwy projektu? Jak miałbyś to przechowywać w bazie danych?

Ważna uwaga: ponowne użycie tłumaczenia stanowi cały punkt scentralizowanej bazy danych, dlatego też zakres tłumaczenia jest przenoszony do jednego projektu

1|hello-world|nl-BE|Hallo Wereld|MyAwesomeApplicatoin1
5|hello-world|nl-BE|Hallo Wereld!|MyAwesomeApplicatoin2

nie jest tak naprawdę poszukiwaną opcją.

Wolałbym coś takiego:

1|hello-world|nl-BE|Hallo Wereld|MyAwesomeApplicatoin1,MyAwesomeApplicatoin2

lub klucz obcy równoważny po prostu umieszczeniu nazw w tabeli.

AKTUALIZACJA

Na podstawie porady dotyczącej normalizacji bazy danych do tej pory wymyśliłem coś takiego:

//this allows me to distinquish if translations where added by developer or by translator

UPDATE2: dodano edmx zamiast tekstu. Jeśli ludzie są zainteresowani, mogę zamienić projekt WCF. Pakuję tę koncepcję, aby inni mogli ją przetestować i wykorzystać.

Uwaga wstępna nr 1: Nie mówisz nam, w jaki sposób obecnie obsługiwane są tłumaczenia

Uwaga wstępna # 2: Twoja baza danych nie jest znormalizowana. Niezależnie od wybranego rozwiązania, najpierw znormalizuj bazę danych . Jeśli nie zrobisz tego teraz, napotkasz później poważne problemy z konserwacją

Tak bym zrobił.

1. Przepisz swoje tłumaczenie, aby przenosiło identyfikator programu z powrotem na serwer

2. Translator zaplecza umieści ciąg w tabeli bazy danych, jeśli jeszcze nie istnieje, i oznaczy go identyfikatorem programu

3. Jeśli ciąg już istnieje, zostanie zaktualizowany tylko wtedy, gdy identyfikator programu pasuje do oryginalnego identyfikatora programu, z którym utworzono ciąg. Jeśli nie, zwróć powiadomienie o konflikcie.

Wariacje:

• Możesz użyć „ID programisty / tłumacza” zamiast ID programu. Uważam to za lepsze, ponieważ są ludzie, którzy znają język obcy i ci, którzy myślą, że znają. Tylko pierwsza grupa ma prawa do modyfikacji.

• Możesz przechowywać identyfikatory wszystkich programów, które używają ciągu w bazie danych, aby wiedzieć, które programy powodują konflikty.

• Możesz rozszerzyć tę myśl o „własności” na każdy język: jedna osoba potrafi mówić po angielsku, a druga po holendersku.

• Gdy baza danych zostanie znormalizowana, dodajesz złożoność kompilacji, np. „Program A jest w językach 1,2,3; B jest w 3 i 5”

Proponuję również napisać osobny program do obsługi tłumaczeń, który pokaże brakujące tłumaczenia itp. Kiedyś to zrobiłem z 2-poziomową autoryzacją: każde tłumaczenie musi być sprawdzone przez drugą osobę (zwykle native speakera).

Ponieważ odnoszą się do „tego” ... możesz raz przypisać nazwę projektu do „tego” (na przykład za pomocą konstruktora), a interfejs funkcji tłumaczących nie zmieniłby się dla koderów. Pod maską dodaje nazwę projektu do zapytania do bazy danych. Alternatywnie możesz podać „to” jako sposób na samodzielne poznanie nazwy projektu. To naprawdę będzie zależeć od tego, jak zorganizujesz swoje zajęcia.

Do przechowywania możesz zrobić coś takiego:

1 ! hello-world ! nl-EN ! Hello World  ! *
2 ! hello-world ! nl-EN ! Howdy, World ! CowboyApp
3 ! hello-world ! nl-EN ! Arrgh        ! PirateApp

Użyj wieloznacznej karty, aby zastosować ogólne tłumaczenie do wszystkich aplikacji, ale nazwę konkretnej aplikacji, jeśli chcesz zastąpić tłumaczenie dla konkretnej aplikacji. Spowoduje to ograniczenie duplikacji do minimum.

Aby zobaczyć, który program używa jakich tłumaczeń, znasz to teraz - jeśli nie chcesz przechodzić i ręcznie zbierać tych informacji, możesz zalogować się do zleceń tłumaczenia.

Jeśli wszystkie projekty są napisane w języku C #, a wszystkie wywołania tłumacza wyglądają tak

this.Translate("hello-world")

gdzie „hello-world” jest kluczem w tabeli tłumaczeń, napisanie małego skanera kodu źródłowego przy użyciu wyrażeń regularnych nie powinno być trudne do znalezienia wszystkich wywołań tłumacza i przypisania słowom kluczowym odpowiednich nazw projektów. W ten sposób nie musisz zmieniać żadnego z istniejących interfejsów kodu lub translatora.

W zależności od rzeczywistej struktury programu alternatywnie może być łatwiej wyodrębnić te informacje z kodu IL twoich zestawów. Jakiś czas temu zrobiłem coś bardzo podobnego, również do celów tłumaczenia, używając tego przykładowego kodu do analizowania zestawów.