Service - Translations: Difference between revisions

From Izara Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 60: Line 60:
Three labels for future query possibilities
Three labels for future query possibilities


# combine subject node label with language code and config table: configKey: "GraphNodeLabel", configTag: "translation"
# combine subject node label with languageCode and config table: configKey: "GraphNodeLabel", configTag: "translation"
# combine subject node label with config table: configKey: "GraphNodeLabel", configTag: "translation"
# combine subject node label with config table: configKey: "GraphNodeLabel", configTag: "translation"
# configKey: "GraphNodeLabel", configTag: "translation"
# configKey: "GraphNodeLabel", configTag: "translation"
Line 66: Line 66:
===== nodeUniqueIdProperties =====
===== nodeUniqueIdProperties =====


Previously planned a unique translationId, but in neo4j feel the text+language properties can be used as the unique id
Previously planned a unique translationId, but in neo4j feel the text+languageCode properties can be used as the unique id


* text
* text
* language
* languageCode


===== nodeProperties =====
===== nodeProperties =====
Line 83: Line 83:
* This relationship is never removed
* This relationship is never removed


==== has{language}{translation} ====
==== has{languageCode}{translation} ====


* All possible translations for each language are linked to their subjectId with a relationship of this type
* All possible translations for each languageCode are linked to their subjectId with a relationship of this type
* When recalculating current translation for a language for each has..translation relationship we add the calculated weighted value to this relationship
* When recalculating current translation for a languageCode for each has..translation relationship we add the calculated weighted value to this relationship
* This relationship is never removed, but those with low weights can be ignored over time
* This relationship is never removed, but those with low weights can be ignored over time


==== current{language}{translation} ====
==== current{languageCode}{translation} ====


* Matches one translation as the currently used translation for one language
* Matches one translation as the currently used translation for one languageCode
* Only one should exist per subject node per language
* Only one should exist per subject node per languageCode
* Languages that have no translations will not have one
* Languages that have no translations will not have one
* Can be removed and replaced when RecalculateCurrentTranslation
* Can be removed and replaced when RecalculateCurrentTranslation
Line 98: Line 98:
==== default{translation} ====
==== default{translation} ====


* Used when no desired language translation exists
* Used when no desired languageCode translation exists
* Initially set to the first translation created, later can move it around eg to English if English gets added later
* Initially set to the first translation created, later can move it around eg to English if English gets added later
* Only one should exist per subject node
* Only one should exist per subject node
* Can create admin logic that goes through a sorted list of languages and applies the first language found as the default
* Can create admin logic that goes through a sorted list of languages and applies the first languageCode found as the default


= SQS queues =
= SQS queues =

Revision as of 09:54, 30 May 2021

Overview

Service manages translations in the service.

Repository

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

DynamoDB tables

Standard Config Table Per Service

Configuration tags

{
	configKey: "TranslationsGraphServiceName"
	configTag: "TranslationsGraphServiceName"
	configValue: xxx // eg: "TranslationsGraph"
}
{
	configKey: "GraphNodeLabelSuffix"
	configTag: "Translation"
	configValue: xxx // eg: "translation"
}
  • combines with subject label/s to create translation node label
{
	configKey: "GraphRelationshipTypeSuffix"
	configTag: "Translation"
	configValue: xxx // eg: "Translation"
}

Graph database

Service - Translations Graph

Nodes

(subject nodes)

  • nodeIdentifierLabels: matches that specific object being translated, eg: catalogName
  • nodeUniqueIdProperties: up to the object and the service that manages it, not set by translation service
  • nodeProperties: (not set by translation service)

translation

nodeIdentifierLabels

Three labels for future query possibilities

  1. combine subject node label with languageCode and config table: configKey: "GraphNodeLabel", configTag: "translation"
  2. combine subject node label with config table: configKey: "GraphNodeLabel", configTag: "translation"
  3. configKey: "GraphNodeLabel", configTag: "translation"
nodeUniqueIdProperties

Previously planned a unique translationId, but in neo4j feel the text+languageCode properties can be used as the unique id

  • text
  • languageCode
nodeProperties
  • text - the text of the translation
  • language - language code

Relationships

has{translation}

  • All possible translations are linked to their subjectId with a relationship of this type
  • This relationship is never removed

has{languageCode}{translation}

  • All possible translations for each languageCode are linked to their subjectId with a relationship of this type
  • When recalculating current translation for a languageCode for each has..translation relationship we add the calculated weighted value to this relationship
  • This relationship is never removed, but those with low weights can be ignored over time

current{languageCode}{translation}

  • Matches one translation as the currently used translation for one languageCode
  • Only one should exist per subject node per languageCode
  • Languages that have no translations will not have one
  • Can be removed and replaced when RecalculateCurrentTranslation

default{translation}

  • Used when no desired languageCode translation exists
  • Initially set to the first translation created, later can move it around eg to English if English gets added later
  • Only one should exist per subject node
  • Can create admin logic that goes through a sorted list of languages and applies the first languageCode found as the default

SQS queues

RecalculateCurrentTranslation

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

  • subject nodeIdentifierLabels: Label/s for the entity being translated, eg: categoryName
  • subject nodeUniqueIdProperties: used to find the specific subject node
  • 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)

Working documents

Working_documents - Translations