[maxpr]

Historically, there are a couple of reasons why developers prefer to i18n their app instead of letting users do that.

1. PostHog has a great tool that lets developers "watch the video" of how users interact with their app's UI. Turns out, automated chrome plugins/built-in features often mess up the HTML so much that apps simply crash. I've seen devs adding translate="no" [0] in bulk to their apps because of this. Therefore, Chrome's built-in auto translation isn't the best solution (yet). 2. Product/marketing folks want users to see content in their language immediately after landing on the website 3. App developers often want to control what users see, update it, rephrase it

If I had to guess, I'd say the approach Lingo.dev Compiler package is using today should end up being a natural part of frameworks like Remix, Next.js and Vue.

[0] https://www.w3schools.com/tags/att_translate.asp

[makeitdouble]

PostHog didn't cross my radar before, so it was an interesting discovery.

I am quite surprise the apps crashes on translation, but then there is a whole user action analytics engine running in parrallel, so it sounds like a problem of having too many things running at the same time ?

Companies that want high control on their translations have already the choice to straight translate their i18n strings, AI or not. That sound to me like a better choice and not much more onerous than the half-baked post filtering we're seeing in this article.

I'd argue if we're going the AI route, having it extract the user text and push it into i18n resources could be a better approach ?

[tough]

posthog is just one of many ways to record a user's session.

the problem is if you have the user running browser extensions which modify the client code from the users' POV. they are also now mangled and not in the standard expected format by those session recording utils.

tbh sounds like it would be a small enough number of users on a big pool it wouldn't matter much in real case scenarios to me