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:


	1. 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
	2. posilam JSON soubor s jinym nazvem -> zjistim posledni translationVersion dane comonenty a verze z DB
	3. posilam preklady jako request body -> zjistim posledni translationVersion dane comonenty a verze z DB


	1. Moznosti registrace novych prekladu do Globalizace:


	1. 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
	2. verze prekladu jiz existuje v DB – smazu vsechny preklady a nahraji nove preklady (translationVersion se nezmeni)
	3. neznam verzi prekladu (napr. jsem ji nevyparsoval z nazvu souboru) – smazu vsechny preklady a nahraji nove preklady (translationVersion se nemeni)


	1. 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.