-
Notifications
You must be signed in to change notification settings - Fork 4
Description
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.