introduce markup placeholders (html, rich text, components, dates)

[samuelstroschein]

💡 Upvote and subscribe to this issue to increase prioritization.

Problem

Users can not use markup placeholders.

See this long thread #1959 (reply in thread)

And this one from https://discord.com/channels/897438559458430986/1110687789395226716/1110903944143712338:

Proposal

Add markup placeholders.

From the message format working group https://github.com/unicode-org/message-format-wg/blob/main/spec/syntax.md#markup-elements

[samuelstroschein]

We have a longer RFC. Feel free to comment on the Google Doc https://docs.google.com/document/d/1uhLrrwKPsenyNsDvZqCl6UXJc5ZBVQYkzn7k5yBuVy0/edit#heading=h.hv9mugtjvm53

[NilsJacobsen]

Do we still use Google Doc for this discussion?

[samuelstroschein]

for the RFC yes

[LorisSigrist]

There are two "levels" at which we can introduce "Components".

1. Markup - Static HTML in messages
2. Full blown Framework Components

Markup shouldn't be that much of a challenge. We can just return markup from the message & tell developers to use their framework's method of rendering stirngs as html
Eg: {@html m.my_message()} in Svelte

However, I don't see a clear path to rendering full-blown components with paraglide's current approach. In some frameworks rendering components isn't possible from a .js file. In others it's possible, but really hard & error prone.

This leaves us with two options:

• Don't support Components in messages
• Have a separate API / runtime for messages with components. This is what react-i18next has devided to do with it's <Trans> component.

Neither one is good. We'll have to come up with something

[NilsJacobsen]

Well, I think the main goal of this is not to have crazy complex components registered, right? Do we even need js for that? I think 98% would be happy with html. One crucial thing, though, is that we want to render the stuff correctly in the editors. So we need the styling, right?

[LorisSigrist]

Markup would be 90% of the use-case. The problem is that NextJS' <Link> component would be another 9% of the use-case.

Do we need to render the components in the editor (show 1:1 what it's going to look like) or would communicating "These components are available, this component is used here" be sufficient?

[NilsJacobsen]

Damn, well, might be a Problem then.
Well, I'm not sure about the styling anymore; you are right; stuff like font size, etc, shouldn't be in there. So, I feel like not having styles in there, makes sense. Took the wrong path in my head.

We can solve the elements step by step, right? Is something wrong with shipping markup first?

[LorisSigrist]

Shipping markup first is what I would suggest as-well. I'm just worried that we might not have a good path forward after that

[kedrzu]

Simple way to introduce placeholders would be to compile message to arbitrary array instead of a string.

For example having a translation:

{
    "hello": "Hello {world}!"
}

It could be compiled into

function hello(params: { world: unknown }) {
    return ['Hello ', params.world, '!'];
}

This way when using in a React or Vue code, you can put a valid Virtual Dom node as a parameter:

<p class="paragraph">
    {{ hello({ world: <b>world</b> }) }}
</p>

To have a single way of doing things, we could also introduce a simple translation function, to render these arrays as strings:

type Translation<P> = (params: P) => unknown[];
function t<P>(translation: Translation<P>, params: P) {
    return translation(params).join('');
}

And use it like:

const helloWorld = t(hello, { world: 'world' });

[samuelstroschein]

Good suggestion.

Using an array will most likely be the right solution. The underlying data structure (a Pattern) is already an array. The main question, and why we are holding back atm, is how to deal with placeholders in apps for translators, designers, etc. Every stakeholder in the localization pipeline must be able to use placeholders. A designer might want to make some text bold, for example.

[kedrzu]

Then I would recommend utilizing Markdown and parse it down to AST using remark package.
AST can be then translated into a native JS function.

It's super flexible approach, and remark has a lot of plugins, like custom directives among others.

This way it's also possible to address other issues like automatically fixing typographic errors (ie. replacing ... with proper ellipsis char), or to put non-breakable spaces to prevent orphans (dangling short words at the end of the line).

I personally am using this kind of approach to introduce a consistent typography engine in my project, where all the texts are provided from CMS and we also need a good deal of flexibility and ease of use.

I'm super excited by your project and would be happy to use it sometime.
If you want, I can share some more details about the approach I'm describing.

[samuelstroschein]

If you want, I can share some more details about the approach I'm describing.

No need thank you.

Markdown is unsuited as i18n syntax. Expressing plurals, gender, and even embedding components is not supported. The complexity of long-form content is also not worth it for short-term content like messages are.

We are deriving our AST from the upcoming MessageFormat 2.0 standard https://github.com/unicode-org/message-format-wg.

[osdiab]

any motion on this as of late? I see pluralization is coming to paraglide, I want to ultimately move our i18n to it, though holding out a bit for things to get more feature complete. thanks!

[LorisSigrist]

We will likely end up adopting something very similar to the Markup syntax described in the ICU MessageFormat 2.0.

I have a working concept ready for how Paraglide will compile messages with components, it's just a matter of getting them into our data-format and making sure the editors can work with it.

I expect Markup to land soon after plurals