Побудова бази даних перекладу рядків для декількох внутрішніх проектів

У нашої компанії є наявна таблиця перекладу ms-sql, яка зберігає такі рядки:

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

У системі є 3 мови, і я думаю, що в майбутньому це зросте до максимум приблизно 10

Ця таблиця читається декількома дуже різними проектами (близько 60 проектів, переважно веб-сайти / веб-додатки та деякі веб-сервіси), що кожен відкриває підключення до бази даних перекладу, кешує переклади

Зворотній зв'язок із передових розробників полягає в тому, що найбільшим недоліком перекладу є наш інтерфейс UIto або модифікація перекладів - це те, що вони не можуть знати, який проект використовує для яких рядків.

Вони іноді змінюють рядки, не знаючи, що вони порушують 7 проектів.

Тепер вони просто мають набрати щось на кшталт, this.Translate("Hello World")а система піклується про інше.

Я міг би, звичайно, змусити їх до чогось подібного, this.Translate("Hello World","AwesomeApplication1")але, схоже, це вимагатиме дуже багато рефакторингу для багатьох багатьох проектів.

Як би ви вирішили запропонувати це рішення? Як би ви як розробник надали перекладу "назву проекту"? Як би ви зберегли це в базі даних?

Важлива примітка: повторне використання перекладу - це вся суть централізованої бази даних, тому розгортаючи переклади до одного проекту, перейшовши

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

насправді не бажаний варіант.

Я вважаю за краще щось подібне:

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

або еквівалент іноземного ключа просто занесення імен до таблиці.

ОНОВЛЕННЯ

На основі поради щодо нормалізації бази даних я поки що придумав щось подібне:

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

UPDATE2: додано edmx замість тексту. Якщо люди зацікавлені, я можу взяти участь в проект WCF, я перекладаю цю концепцію, щоб інші люди могли її перевірити та використати.

Попередня примітка №1: Ви не кажете нам, як підтримуються переклади на даний момент

Попередня примітка №2: Ваша база даних не нормалізована. Яке б рішення ви не приймали, спочатку нормалізуйте свою базу даних . Пізніше ви зіткнетесь із жахливими проблемами з технічним обслуговуванням, якщо цього не зробите зараз

Це я би робив.

1. Перезапишіть перекладацький дзвінок, щоб він переніс ідентифікатор програми на сервер

2. Перекладач із зворотнього кінця помістить рядок у таблицю бази даних, якщо вона ще не існує, і позначить її ідентифікатором програми

3. Якщо рядок уже існує, вона оновлюється лише у тому випадку, якщо ідентифікатор програми відповідає оригінальному ідентифікатору програми, за допомогою якого створено рядок. Якщо ні, поверніть повідомлення про конфлікт.

Варіації:

• Ви можете використовувати "ідентифікатор розробника / ідентифікатор перекладача" замість ідентифікатора програми. Я вважаю це кращим, оскільки є люди, які знають іноземну мову, і ті, які думають, що знають. Тільки перша група має права на модифікацію.

• Можливо, ви захочете зберегти ідентифікатори всіх програм, які використовують рядок у БД, щоб ви знали, які програми конфліктують.

• Ви можете розширити цю думку про власність на кожну окрему мову: одна людина може володіти англійською, інша голландська.

• Після нормалізації вашої бази даних ви додаєте складність складання на кшталт "Програма A є мовами 1,2,3; B - в 3 та 5"

Я також пропоную вам написати окрему програму «підтримка перекладу», яка покаже вам відсутні переклади тощо. Я колись це робив з дворівневою авторизацією: кожен переклад повинен бути перевірений другою людиною (зазвичай носієм мови).

Оскільки вони посилаються на "це" ... ви можете призначити ім'я проекту один раз на "це" (наприклад, через конструктор), а інтерфейс до функцій перекладу не зміниться для кодерів. Під кришкою він просто додає назву проекту до запиту бази даних. Крім того, ви можете надати "це" засобом пізнання назви проекту самостійно. Це дійсно залежатиме від того, як ви структурували свої класи.

Для зберігання можна зробити щось на кшталт:

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

Використовуйте підстановку, щоб застосувати загальний переклад до всіх програм, але конкретну назву програми, коли ви хочете змінити переклад певного додатка. Це дозволить звести дублювання до мінімуму.

Щоб побачити, яка програма використовує переклади, тепер ви це знаєте - якщо ви не хочете переглядати та вручну збирати цю інформацію, ви можете записати запити на переклад.

Якщо всі ваші проекти написані на C #, а всі дзвінки перекладача виглядають приблизно так

this.Translate("hello-world")

де "привіт-світ" є ключем у вашій таблиці перекладу, не слід надто важко написати невеликий сканер вихідного коду, використовуючи регулярні вирази, щоб знайти всі виклики перекладача та призначити ключовим словам відповідні назви проектів. Таким чином, вам не доведеться змінювати будь-який існуючий код або інтерфейс перекладача.

Залежно від реальної структури вашої програми, можливо, простіше отримати цю інформацію з IL-коду ваших зборів. Я робив щось дуже подібне деякий час тому, також для цілей перекладу, використовуючи цей приклад коду для розбору збірок.