extract message to selected inline preview language (user preferred language)

[felixhaeberle]

Problem

Currently, the message gets always inserted into the source language but in regard to the mental model, it would be beneficial if the user gets the message inserted in the preview language which is selected.

This could lead into confusing behavior and also doesn't work then when extracting a message: when other than the source language is selected as inline preview language, the extract process yields an error for the inline preview because the message is then not there for the changed language ut only for the source language.

Solution

Enable extracting into the current preview language to follow the mental model of the user.

[samuelstroschein]

it would be beneficial if the user gets the message inserted in the preview language which is selected.

Probably not. A team develops in one language. You are now risking that someone extracts a message into different (source) languages. Chaos will be the result.

Besides, how is this contributing to growth?

[felixhaeberle]

A team develops in one language.

@samuelstroschein Yes, you said it! And if this language isn't the source language, as we already made the experience various times – the team needs a way to extract in their language, even tho the source language isn't their main one.

You are now risking that someone extracts a message into different (source) languages.

Not source language, but language yeah. Our lint rules do perfectly monitor what is missing – why don't give this opportunity? It's the same situation for @opral/inlang-fink when we allow to create a new message. You can't guarantee if the source language or any other language is filled in first OR if the contributing user does know the source language.

@NiklasBuchfink How does Fink handle create new messages for non source language users?

Besides, how is this contributing to growth?

Not, but its an issue regardless, and I wanted to create it for future reference.

[NiklasBuchfink]

@felixhaeberle Fink can't create new messages yet.

[felixhaeberle]

@NiklasBuchfink Thanks, I know this. My question was not precise enough.
-> How do you imagine this feature to turn out in Fink?

[samuelstroschein]

@felixhaeberle it does not seem to matter what finks will or will not do.

OR if the contributing user does know the source language.

this feature request seems to be a distraction guided by potentially wrong assumptions. A contributor won't create new messages. A contributor might create or update a variant of a message. I can't imagine devs writing hardcoded text in another language than the source language. The chaos would be crazy: "Why is the source variant Chinese instead of [source language tag]?" "Because I write hardcoded text in Chinese???" No conversation ever.

I might be proven wrong. But no user asked for this, and neither is it contributing to growth. Why invest resources into this?

[felixhaeberle]

@samuelstroschein I agree with this.

But, we have a UX flaw here. I'll record a 1min Loom tomorrow & then we decide if we can close this issue as won't fix.

[felixhaeberle]

@opral/team should we allow extracting in different languages than the source language?
https://www.loom.com/share/174b02d684d54dd6aecd9699fca94788 – jump to 03:10 for quick summary

[jannesblobel]

I like the feature and think we should work on it in the future. Therefore, I vote that we should turn this issue into a feature request and postpone it :)

[NiklasBuchfink]

Not all apps have something like a preview language. Everything is engineered so you shouldn't start with "de" if the project's source language is "en".

In your case and also in Fink:

• you generate an ID
• extract to text to "de"
• "en" is missing as the source language

---

• I can't machine translate if "en" is the source language
• If you can select a different source, you lose the common sense of a team from where to where the copy flows (source -> others)
• the lint reports are different depending on who chooses which language
• you have gaps everywhere and now you need to translate back and forth around those gaps.
  (I can't hire a team, give them the well-thought-out English copy and then have it translated into 10 different languages because the German team did their part in German and the Chinese team did their part in Chinese. Translate from de to en to zh and from zh to en to de or if a person can de to zh, but image this for 10+ languages).
• "tree-shaking" for outdated messages (source changed -> other languages are outdated) gets more complicated

That's the issues I see coming with this proposal. Everything gets x times more complicated. Let's wait until this is requested by users and required for real-world workflows.
In the best case, the designers deliver the first version with Parrot and the developer does not have to extract any messages or copy the language from the design, which should also match the source language.

[samuelstroschein]

here is my proposal https://www.loom.com/share/7ea97c098caa4a13a2b871d0ddfc8a16

• have a pre-filled prompt which language tag the extracted message has (simple enter is enough for 90% of use cases)
• remove inlang language selection in the bottom right nav bar and move it to the tab and inline decoration to increase discoverability of the feature