Rename Inlangs message id to „name“ or „key“.

[martin-lysk]

In the current state of Inlang sdk and eco system, the "Id" property, which is used for querying messages in CRUD operations, actually represents a messages name or key not the identifier.

When it comes to an Id, it's important to note that the message name lacks a crucial property - immutability. You can find more information on this topic here: Link to Immutable Identifiers. The historical reason for this lack of immutability is due to the absence of immutable Ids in most message formats available. For instance, in i18next, it functions as a key-value store where the message name points to its variants, either in a flat structure or nested.

Why is an immutable id important if almost all string files out ther lack on an identifier?
The rationale behind this design is that these formats were originally intended to be editable by humans. Requesting a human to assign a unique Id that they must maintain within a file, or even across multiple files (one per language), is not a practical approach. This approach doesn't even work effectively for the key name itself in many cases. For a single system that sources these string files and references messages by name, using an immutable Id doesn't provide any significant benefit.

While the absence of an immutable Id isn't currently a problem for Inlang's existing feature set, it will become a requirement for future iterations to enable the implementation of features such as:

• Review processes (tracking whether a message variant has been reviewed by a translator)
• Changing message names
• Providing message history in the editor
• Name/key aliases (using different keys for different platforms)
• Referencing messages in applications like Parrot
• Attaching metadata to message variants through plugins
• Exporting to multiple platforms

It's crucial to consider this change as soon as possible, even if these features may be part of future plans. The Id is extensively integrated into Inlang's infrastructure because it plays a central role in core CRUD actions, like the example below:

inlang.query.messages.upsert({ where: { id: 'welcome_msg' } });

While the discussion regarding the Id system is a separate topic, I recommend initiating a discussion on this matter and referencing it here. Delaying this change will only result in exponentially growing challenges as Inlang's ecosystem and adoption continue to expand.

[samuelstroschein]

We discussed this already. I oppose renaming ids to key. We can additionally introduce keys in the future. But it's not a problem at the moment.

A translator/designer/developer will make the mistake of renaming a message-id exactly once. Through version control, the old message id can be retrieved.

[felixhaeberle]

Agree with Samuel 👍 Offtopic idea: It would be helpful to have something like a content type prefix**m-**191c0087-1a6d-42e4-bb20-83f669cfa099 which we can immediately recognize while debugging when introducing more content types beyond messages.

@samuelstroschein Or did I misunderstand this and you don't want to introduce uuid in the future?

[samuelstroschein]

Yeah, ids in the future a random strings/hashes whatever.

[samuelstroschein]

@martin-lysk

did we agree on the following?

What

• ids are not going to be renamed
• treat ids has immutable. if someone changes an id -> they will learn their lesson
• parrot has to keep metadata itself for features that are not yet provided by the inlang SDK

Why

• inlang can grow far without handling messages renames properly now
• changing ids now to key/name would introduce unforeseeable complexity now or in the future
• introducing additional properties like name is possible in a non-breaking manner in the future

[felixhaeberle]

@samuelstroschein "they will learn their lesson" -> How do lint rules come into play here?

[samuelstroschein]

They dont. We can't lint a message id change