search

opral / inlang-message-sdk

0 stars 0 forks source link

Requirements for message persistency #29

Closed samuelstroschein closed 1 month ago

samuelstroschein commented 2 months ago

Context

This is a discussion issue for sdk persistency project requirements.

Why do we need persistence?

Inlang projects should provide built-in persistence instead of relying on developers to create text files with formats which may not support globalization needs.

Our goals with this work

  1. To simplify the inlang getting-started experience. Users create new inlang projects in 1 click => A project has built-in message storage.
  2. To support high-demand features like plurals, gender etc. Inlang projects store message variants, match patterns etc.
  3. To offer a smooth transition from directly editing messages in text files, to editing messages via a UI like Fink or Sherlock.
  4. To enable change-driven workflows e.g. across translators, developers, and designers.
    This means (a) mapping persisted message state changes to repo diffs/merges/commits, and (b) persisting repo workflow state like reviews and approvals alongside the persisted messages.
  5. To enable high quality, context aware, AI-assisted globalization.

Timeline considerations

In the short term, feature coverage (plurals, gender etc.) and human editability are most important. This speaks for shipping MVP persistence together with editor support ASAP.

jldec commented 2 months ago

I'm wondering if human-editability of persisted text files really is an all-or-nothing question.

Would it be possible to store messages in JSON (or similar) text files in a way which maintains human editability for the simple cases (1 string => 1 translation per langage) and uses a non-editable (AST-like) represenation for the more complex cases e.g. with match logic.

samuelstroschein commented 2 months ago

@jldec I'm wondering if human-editability of persisted text files really is an all-or-nothing question.

The message SDK needs a (sqlite) database in the long run. The moment lix allows us storing a .sqlite database, the message persistency question is solved and with it the arguments around human readability.

The other case that can be made is:

Option A - Custom message persistency takes us 3 months
Option B - Sqlite storing .inlang file takes 4 months (by enabling support in lix)

Option B will be better but problem: Will support for sqlite files break git compatibility?