Service - Translations: Difference between revisions

From Izara Wiki
Jump to navigation Jump to search
(Created page with "= Overview = Service manages translations in the service. = Repository = https://bitbucket.org/stb_working/translations/src/master/ = DynamoDB tables = == Standard Conf...")
 
No edit summary
Line 29: Line 29:


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.
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.
= Types of Project Graph relationships/edges =
Links between possible translations and the object they are translating are stored in the Project Graph as edges. Each possible translation is a vertex.
== Edge label: {translationLabel}Translation ==
* All possible translations are linked to their source object with an edge of this type
* A users support for a translation is connected to this edge (or to the translation vertex if unable to link to an edge)
* When recalculating current translation for a language we add the calculated weighted value for each possible translation to this edge as a property
* This type of edge is never removed, but those with low weights can be ignored over time
== Edge label: {translationLabel}Translation{languageCode} ==
* Matches one possible translation as the currently used translation for one language
* Only one should exist per source object per language
* Languages that have no translations will not have one
* Can be removed and replaced when RecalculateCurrentTranslation
== Edge label: {translationLabel}TranslationDefault ==
* Used when no desired language translation exists
* Initially set to the first translation created
* Only one should exist per source object
* Can create admin logic that goes through a sorted list of languages and applies the first language found as the default
= How translations are found for users =
Plan is to allow users to create ordered lists of prefered languages (and perhaps automatic translating as a last option?), these lists can be shared, 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 TranslationDefault option.
Will need to cache results for efficient resource use.


= Working documents =
= Working documents =

Revision as of 06:41, 16 February 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

SQS queues

RecalculateCurrentTranslation

Add to this queue the translationLabel, languageCode, subjectId, translationId:

  • translationLabel: Name for the entity being translated, eg: categoryName, is used to create id/indexes in ProjectGraph
  • languageCode: see below
  • subjectId: is the vertex id in the Project Graph for the entity that has a relationship with the translation, eg catalogCategory
  • translationId: is the vertex id in the Project Graph for the translation

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.

Types of Project Graph relationships/edges

Links between possible translations and the object they are translating are stored in the Project Graph as edges. Each possible translation is a vertex.

Edge label: {translationLabel}Translation

  • All possible translations are linked to their source object with an edge of this type
  • A users support for a translation is connected to this edge (or to the translation vertex if unable to link to an edge)
  • When recalculating current translation for a language we add the calculated weighted value for each possible translation to this edge as a property
  • This type of edge is never removed, but those with low weights can be ignored over time

Edge label: {translationLabel}Translation{languageCode}

  • Matches one possible translation as the currently used translation for one language
  • Only one should exist per source object per language
  • Languages that have no translations will not have one
  • Can be removed and replaced when RecalculateCurrentTranslation

Edge label: {translationLabel}TranslationDefault

  • Used when no desired language translation exists
  • Initially set to the first translation created
  • Only one should exist per source object
  • Can create admin logic that goes through a sorted list of languages and applies the first language found as the default

How translations are found for users

Plan is to allow users to create ordered lists of prefered languages (and perhaps automatic translating as a last option?), these lists can be shared, 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 TranslationDefault option.

Will need to cache results for efficient resource use.

Working documents

Working_documents - Translations