ship default human ids in sherlock already

[samuelstroschein]

Context

We can avoid discussions like https://discord.com/channels/897438559458430986/1247937929876082839/1248258473851093054 and substantially improve the UX of extracting messages already by shipping human ids in sherlock on extraction before importers/exporters arrive.

Proposal

Ship default filled in human ids in sherlock now to:

• avoid discussions around naming keys for greenfield paraglide projects
• increase the UX of sherlock (coming up with names is so frustrating!)

Scenarios

BEST CASE:

The human ids sherlock uses will be the human ids that the SDK uses which means no aliases will be used once importer/exporter ships

WORST CASE:

The human ids differ from the importer/exporter ids the SDK will use. In that case, the human ids will be treated as aliases. AKA Status quo. Still a better UX for sherlock and paraglide users in the meantime.

[samuelstroschein]

@martin.lysk1 @jldec is a human id generator function exposed by the sdk?

const id = generateMessageBundleId()  

[martin-lysk]

Yes this should do the trick:

https://github.com/opral/monorepo/blob/fb731c9c25958a8df089c636217fbb7916bdddbd/inlang/source-code/sdk/src/storage/human-id/human-readable-id.ts#L5

[felixhaeberle]

I will enable this for the experimental usage of human readable ids.

[samuelstroschein]

I will enable this for the experimental usage of human readable ids.

the proposal is explicitly to enable this now for everyone. we don't have to wait for sdk features.

were you confused by the proposal or have concerns about enabling this now for everyone?

[martin-lysk]

We talked about this earlier and I just recaled you rejected this back than for the reason you outlined in the worse case. If we introduce human identifier we will end up with two human ids for one message bundle because we would import those messages and the id's we find will be handled as foreign id's inside of aliases and we would create an identifier for each message on creation.

We could check if the id is a human id (each word is known) already and don't create an alias?!

[samuelstroschein]

We could check if the id is a human id (each word is known) already and don't create an alias?!

Yes, that's what I had in mind with this proposal.

(Back when we discussed introducing human ids 8-12 weeks ago, I was not aware how long it would take. So, I'd say now ship it in sherlock and be aware in MESDK-66 that messages that obey to a human readable id should not be imported as alias)

[felixhaeberle]

were you confused by the proposal or have concerns about enabling this now for everyone?

This would hurt the vast majority of users (like everybody right now) who have other naming systems. Providing them with this wrong default (in their case) would dramatically reduce DX & lead to inconsistent key naming which they gonna try to avoid.

"Of course, they don't have to accept this default" you might say, but this really feels like the wrong thing to do from Sherlock staying unopinionated about keystyles.

Results: Lots of open issues & bugs where people request other defaults or options.

Worst: User switches to other solution which is unopinionated about keystyle.

---

Proposed solution:

• Extend API extractMessageOptions / Create new API defaultMessageID in the plugin app config for Sherlock
• providing a default per plugin on how to handle the message id per plugin
• then go ahead and do the proposed change of defaulting to human readable ids in the inlang message format.

[samuelstroschein]

This would hurt the vast majority of users (like everybody right now) who have other naming systems.

I heavily doubt this. Can you ship this feature and if users complain deactivate it again?

We are running into endless discussions with naming things. Just ship this.

[jldec]

fyi randomHumanId() is now exported on the @inlang/sdk api.
https://github.com/opral/monorepo/pull/2930

[samuelstroschein]

@felix.haeberle are you gonna ship this?

[felixhaeberle]

yes, its on my list for today.

[felixhaeberle]

@samuel.stroschein Satisfied?

I can't change the Enter/Escape part.

I haven't done any opt-in / opt-out behavior as of now. Will do that with the first complain (100% sure about people will complain and want this to be modified) – thought about sherlock.extract.autoHumanId which defaults to true but can be set to false.

[samuelstroschein]

I haven't done any opt-in / opt-out behavior as of now

I don't think it will be needed.

[samuelstroschein]

yes, baba let's goooo!

[jldec]

👶 🚀