Hoj,
dle dohody posilam popis ocekavaneho chovani Globalization service:

1. Uprava DB modelu - ComponentTranslation bude obsahovat “translationVersion”, z Translation se vyhodi “version”.

2. V DB bude existovat vzdy pouze jedna verze prekladu (translationVersion) pro kombinaci componentId + componentVersion. Tzn.  pokud budu nahravat novou verzi prekladu, stara verze se vzdy smaze. V DB tedy nemame historii prekladu, protoze si je muzeme kdykoli stahnout z repository.

3. Endpointy v Globalizaci neni potreba menit, translationVersion se bude zjistovat z nazvu souboru nasledovne:
	- posilam JSON soubor, ktery v nazvu obsahuje componentVersion a translationVersion (tj. ma format dle SHA-921: %service_name%%iso_code%%service_version%_%translation_version% (e.g. FileSharing_en_US_1_12)) -> zaregistruji preklady k dane componentVersion
	- posilam JSON soubor s jinym nazvem -> zjistim posledni translationVersion dane comonenty a verze z DB
	- posilam preklady jako request body -> zjistim posledni translationVersion dane comonenty a verze z DB

4. Moznosti registrace novych prekladu do Globalizace:
	- registruji novou verzi prekladu, tj. kombinace componentId + componentVersion + translationVersion neexistuje v DB – smazu vsechny preklady v tabulce Translation pro danou componentId + componentVersion, nasledne nahraji novou verzi prekladu a zaktualizuji translationVersion
	- verze prekladu jiz existuje v DB – smazu vsechny preklady a nahraji nove preklady (translationVersion se nezmeni)
	- neznam verzi prekladu (napr. jsem ji nevyparsoval z nazvu souboru) – smazu vsechny preklady a nahraji nove preklady (translationVersion se nemeni)

5. Odpada tedy logika, kdy se aktualizovaly jednotlive preklady (key,value v Translation) a v DB zustavaly i stare hodnoty. Tj. je potreba zoptimalizovat TranslationPackageJsonParser.

Snad je to jasne, pripadne se ptej.