Service - Translations

Overview

Service manages language translations.

Repository

https://bitbucket.org/stb_working/translations/src/master/

DynamoDB tables

Standard Config Table Per Service

Configuration tags

{
	configKey: "TranslationGraphServiceName"
	configTag: "TranslationGraphServiceName"
	configValue: xxx // eg: "TranslationGraph"
}

LogicalResults

Stores results for any requests to perform logical searches on media links

{
	resultId: xxx // eg: filterMainId for a single logical element
	dataId: xxx // one translationLinkId or one subject nodes identifier (the logical request will set what property should be used)
}

• partition key: resultId
• sort key: dataId

Graph database

Service - Translations Graph

• {textTag} is the name of the text being translated, eg a Catalog subject node will have a textTag "catalogName"

Nodes

{
	nodeLabel: "{TranslationSharedLib.translationLinkNodeLabel()}", //eg: translationLink
	schema: {
		identifier: true,
		restrictProperties: true,
		restrictRelationships: true,
		properties: {
			translationLinkId: {
				identifier: true, // create unique id from request details
			}
			languageId: {
				immutable: true,
			}
			textTag: {
				immutable: true, // tag of what text is being translated
			}
			weight: {
			}
		},
	}
}

• creates a link between a subject node and a translation text
• when recalculating current translation for a languageCode we add the calculated weighted value to this node as a property

{
	nodeLabel: {TranslationSharedLib.TRANSLATION_GRAPH_NODE_LABEL}, //eg: translation
	schema: {
		identifier: true,
		restrictProperties: true,
		restrictRelationships: true,
		properties: {
			text: {
				identifier: true,
			},
		},
	}
}

(subject nodes)

Subject node schemas are managed by each service that needs translations, normally as a basic schema with identifier properties only.

• nodeIdentifierLabels: matches that specific object being translated, eg: catalog
• nodeIdentifierProperties: matches that specific object being translated, eg: catalogId
• nodeProperties: Can store additional properties, not set by translation service
• node schema should set identifier = true, immutable = true (which includes elementCanBeRemoved = false)

Relationships

{
	relationshipType: "{TranslationSharedLib.translationLinkHasRelType()", // eg: has_translationLink
	schema: {
		immutable: true,
		restrictProperties: true,
		properties: {
			originTimestamp: //timestamp the request to create/change this relationship was sent
		},
	}
}

• every translationLink will have this relationship
• is never removed, but those with low weighted links can be ignored over time

{
	relationshipType: "{TranslationSharedLib.translationLinkCurrentRelType()}", // eg: current_translationLink
	schema: {
		elementCanBeRemoved: true,
		restrictProperties: true,
		properties: {
			originTimestamp: //timestamp the request to create/change this relationship was sent
		},
	}
}

• the currently used translationLink for the language the link points to
• only one should exist per subject node and textTag/languageCode combination, but each language for each textTag will have it's own current relationship
• this relationship will not exist for languages that have no translations
• can be removed/added when RecalculateCurrentTranslation

{
	relationshipType: "{TranslationSharedLib.translationLinkDefaultRelType()}", // eg: default_translationLink
	schema: {
		elementCanBeRemoved: true,
		restrictProperties: true,
		properties: {
			originTimestamp: //timestamp the request to create/change this relationship was sent
		},
	}
}

• sets the default translationLink to use when no translationLink for the requested language/s exist
• can be changed but each subject/textTag must have 1
• initially set to the first translation created, later can move it around eg to English if English gets added later
• could create logic that goes through a sorted list of languages and applies the first languageCode found as the default

{
	relationshipType: "{TranslationSharedLib.isTranslationDefaultRelType()}",
	schema: {
		elementCanBeRemoved: false,
		allPropertiesImmutable: true,
		restrictProperties: true,
		properties: {
			originTimestamp: //timestamp the request to create/change this relationship was sent
		},
	}
}

Complex Filter requests

{
	filterType: "XXX" // up to calling service
	type: "group",
	elements: 
	[
		{
			type: "logical",
			logicalTag: "textTag_languageId_text",
			resultType: "mediaLinkProperty"
			textTag: "mediaLinkPropertyValue",
			languageId: "en",
			text: "Blue",
			subjectIdentifierPropertyName: "propertyId",
			caseSensitive: true
		},
	]
}

- searches for specific and full text, optional case sensitive - finds an identifier property on the subjects node and stores in LogicalResults for the request - resultType must exist in request because want it to match filterType and Translation has no way of knowing filterType of request

SQS queues

RecalculateCurrentTranslation

Add to this queue the subject nodeIdentifierLabels, subject nodeIdentifierProperties, languageCode

• subject nodeIdentifierLabels
• subject nodeIdentifierProperties
• languageCode: see below

This queue does not have a Lambda trigger, we could poll it when resource costs really cheap as it is low importance (and/or have an API endpoint that polls and processes a batch).

Language codes

Considering using ISO 639-3 codes and designing a way to substring them to automatically go up the hierarchy if no lower level variants match, an alternative would be to allow users to create ordered lists of preferred translations and share these.

How translations are found for users

Plan is to allow users to create ordered lists of prefered languages (and perhaps optionally automatic translating as a last option?), and new users are automatically set to a list depending on their location when signing up.

For each text to translate: work through the list and find the first matching translation, if none found fall back onto the default option.

cache results for efficient resource use.

System text translations

System text follows the same Label + UniqueIdProperty system to identify specific translation subjects (one system text output), the labels and unique ids can set in npm modules.

• Label example: hard coded or as a constant in NavBar service: "sysTxtNavBar"
• UniqueIdProperty example: "sysTxtTag", value: "SignOut" (can set as a constant in NavBar service)

• Label example: NPM module - izara-market-shared#CatalogManagerLib.constants.sysTxtCatalogManager ("sysTxtCatalogManager")
• UniqueIdProperty example: "CatalogName", value: NPM module - izara-market-shared#CatalogManagerLib.constants.CatalogStandard.catalogName

Working documents

Working_documents - Translations