Skip to content

Proposal: Include multiple properties in a translation doc #1130

@gmaclennan

Description

@gmaclennan

Currently we create a separate translation doc for each property that is translated. The schema is approximately:

interface Translation {
  docRef: DocRef; // ref to document being translated
  propertyRef: string; // identifier for translated field/property in dot-prop notation
  languageCode: string; // three-letter ISO 169-3 language code
  regionCode?: string; // two-letter country code from ISO 3166-1 alpha-2 or a three-digit code from UN M.49 for geographical regions
  message: string; // the translated string
}

This creates excessive overhead for writing, indexing and reading, because all properties of a doc are always translated together.

I propose we change the translation schema to include multiple properties:

interface Translation {
  docRef: DocRef; // ref to document being translated
  translatedProps: Record<string, string> // Map of dot-prop notation properties to translated messages
  languageCode: string; // three-letter ISO 169-3 language code
  regionCode?: string; // two-letter country code from ISO 3166-1 alpha-2 or a three-digit code from UN M.49 for geographical regions
}

I think we can implement this in a backwards-compatible way by using a custom getWinner function on the indexer for translations which, if the document being indexed is the old translation v1, attempts to merge the values in the indexer. If there is no conflict (e.g. each doc refers to a different property), then the merged value translatedProps should be written to the db. We can say that the new schema version always "wins", since there would never be a case where a single property translation from the old schema should take precedence over the new schema and a doc translating all properties.

This should reduce the time needed for project creation and initial sync because it should reduce the number of translations docs written and indexed. The total number will only increase as we add new languages, and currently we translate 3 properties for each field doc (plus one for each option if a select or multi-select, which is common), and 2 properties for each preset. Combining into a single translation doc for each translated doc should reduce translation records between 2-5x.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions