search

opral / inlang-paraglide-js

Tree-shakable i18n library build on the inlang ecosystem.
https://inlang.com/m/gerre34r/library-inlang-paraglideJs
22 stars 0 forks source link

Paraglide - Use string exports when an invalid JS identifier is used #144

Closed LorisSigrist closed 4 weeks ago

LorisSigrist commented 4 weeks ago

Context

Apparently you can export stuff as arbitrary strings, not just variable names.

export { something as "arbitrary string"}

No one ever does this because Typescript doesn't support it. That is, it didn't support it. Support just came out in the nightly release & will land soon.

Proposal

Export message IDs that aren't valid JS identifiers this way. They can be used like this:

m["my.message.key"](params)

This would remove a lot of the unnecessary limitations about message IDs that currently exist in paraglide

LorisSigrist commented 4 weeks ago

@felix.haeberle would we need to update the m-function-matcher to make this work?

samuelstroschein commented 4 weeks ago

i wouldn't add this. this introduces complexity with no benefit once human ids ship except for legacy projects. but even in legacy projects, they can incrementally adopt paraglide js next to their existing i18n library. for all paraglide messages, they should (i argue must!) use human ids.

@LorisSigrist are you sure you want to add this? If so, please provide arguments why human ids are not a vastly superior user experience

LorisSigrist commented 4 weeks ago

Closed in anticipation of Human IDs.
See: https://discord.com/channels/897438559458430986/1247937929876082839/1248258473851093054