I think that ideally, every project would be setup from scratch in the beginning to use t() tags or something similar to have translation keys so that setting up translations is as easy as swapping out what t() returns (from e.g. a config file or the like).
Of course, we all know that this is very rarely how projects end up getting setup especially in the early stages, and then it's just massive amounts of work to go back and set it up later.
The thing that's the most intriguing to me about what you're describing is automatically setting up translations in the build step where you auto-detect strings to translate. But looking at the site, most of it seems to be focused around the VSCode extension which will just sort of find and replace strings in the source code with t() tags.
Can you talk more about the translations in the build step? Is there a reason you're not talking more about that on the site? (Is it just newer, not very reliable/good, or...)?
The idea that I could just throw something like this into my project, not have t() tags in my source code but still get translations, sounds like magic and I think it would be really neat.
Yeah, we've noticed that companies in the early stage ignore i10n completely and then eventually realize it's going to be a huge lift to retroactively support it
So, for the build time translation-
Yeah, I would say it's not reliable yet =p
But, it's not that far off. It's not magic- the idea is that we inject the t functions at build time so that they don't need to be in your code. The vscode extension is a good visual for this- for many patterns, it correctly notices what does or doesn't need to be translated.
But, the real problem is that if a process like this goes awry (a strange pattern leads to text being erroneously translated/untranslated) then it is next to impossible for someone to debug.
Glad you think this is cool. We think this is absolutely on the horizon, and we hope to be the first to get people using it... but in the meantime, we don't want to be responsible for issues on prod...
> companies in the early stage ignore i10n completely and then eventually realize it's going to be a huge lift to retroactively support it
That's the correct thing to do. When you're first building a product you're trying to prove that it can and should exist: that you can get people to pay you money for it. It doesn't make sense to spend your time or money doing anything else.
Once you're successful then you know that people in one country like your product and maybe people in another company will as well. But until you know that, that's the only thing you should be working on.
Yes! I've seen multiple products that were only in English, translations were a super annoying productivity blocker (build step required), tens of unused string keys, keys not matching the it's content etc. Please don't localize until the product is at least 95% "finished".
On this, I just want to share my take-away from my translation engineering days: I fully believe the "right way to do it" is to have two string types: A regular string type and a "user-visible string" type, in a similar way that some frameworks expose a "safe string" vs "unsafe string" (for escaping purposes).
User-visible strings are consistently translatable, and the translation mechanism needs to have deep access in the language for this. I think in typescript this is a fairly doable thing given the AST access you yourself make use of. I'll gladly dig into how you do this on your end but I'm guessing it's somewhere along those lines but not quite?
Incidentally, when you have two string types, it becomes fairly straightforward to detect strings that probably should be translated but aren't tagged as such. Most strings are like this, in fact, because string constants tend to be a bad idea in general (vs numeric constants), and string operations tend to be a bad idea in the context of i18n (you want to use templated strings instead). So you tag until you only have a few left-over.
Yeah, this tracks! The steps are basically 1) determine user facing elements 2) determine strings 3) map user facing elements to the string. (We use the ast and no llms for this)
The upside of this approach is that we get a lot of context for accurate translation. The other upside is that down the line we can pull off fully automatic translation, but as others have pointed out, this is more of a gimmick. We think it's cool but it's more like the cherry on top
Also, yeah, that pattern would make life infinitely easier. Most develors really should think like this already, and not mix user facing strings with strings for other logic. But from what ive seen, pre i18n, devs dont think like this. Someday...
Interesting approach! I like the idea of using an ast to find translation strings and to generate source strings by an llm from the context. My experience is the same. Having to deal with 6 languages and a fast changing application is impossible for small teams, so I ended up with asimilar approach where developers only edit the source text, and target translations are automatically kept in sync using Deepl. This solves the whole i18n dilemma of outdated/missing translations, by just focussing on the source texts. It would be great to be able to even generate the source texts from the $t tag. I'm slowly turning this into an open source developer tool: https://garage44.org/posts/expressio/expressio-machine-trans...
This is a great idea. I have even hit this pain point when developing a healthcare app for hospitals that was primarily used in the United States. There are certain communities, even just within California, where it is common to have patients who only understand Spanish, Mandarin, or Japanese.
Any plans to extend this to iOS/Android development in the future? I assume it would already be easy to integrate this into React Native.
Also, is there a way for me to provide explicit additional context to the `t` function for the translation? Essentially a string that is appended to the LLM input for translation. For example, in Japanese there is often a significant difference between formal and informal language, and it is common to add post-positional particles such as や, が, and の to make titles and labels sound more natural. I see you have addressed many other special cases around numbers/dates/etc, so certain flags like formal/informal, regional dialect, etc may be valuable future additions.
Overall looks really nice and I look forward to trying this the next time the need arises.
Right now we actually do have React Native support, it is now in our docs! As for adding manual context, we're planning on adding that, but we don't want people to go overboard with adding additional context where it's not needed. We want to have suggestions for if we need additional context beyond what we get from the tree traversal. Also, in terms of tone/regional dialect, that's something we're adding into the dashboard so that all translations will have that info passed to the LLM to maintain consistency throughout the app!
I have been using a very similar approach for i18n of my eternally experimental web game https://luduxia.com/reversi/ which has an entertaining build process including this sort of thing. (I come from a game publishing background so have nightmares of when we all sent Excel sheets around motivating these things).
Does your result live update the strings in place if the device locale is changed?
Do you have any method for getting feedback from UI tests? I don’t now, but that is absolutely a feature I was used to previously. We used to OCR off expected areas to ensure things fit etc.
The computer kicked my ass. I had forgotten why I disliked othello...
As for the UI/UX tests, we're looking to integrate with PostHog and work with another company in our batch (PathPilot) which focus on analyzing user experience
Once we work these analytics in, the theory is we can better predict UI issues and resolve them retroactively. A full UI testing suite is something people have asked for, and we aren't there yet, but the tools are here
Yeah, we detect off the browser what locale we should switch into. As for UI tests, we're doing that ad-hoc right now for everybody, but what was your favorite approach to that? I'd love to look into what the best ways people handled that in the past and how we can improve on it
This was for video games (console, pc, mobile) but we had a framework where a video feed went into a host machine and you could get it to ocr read areas off the screen. This was then used to guide user input (i.e. find the right button if it had been moved) but also had checks for if strings exceeded bounding dimensions.
The classic always used to be German overflows, but these days the wrong sort of Chinese and RTL is more of a headache. (I have been ignoring proper RTL for a while).
I have also noticed LLMs get stuck in healthy/unhealthy loops when doing this sort of work. If you can snapshot the state of them when they are doing the right thing it would be very useful. They also build a lot of good per app context which improves the result quality.
Ahh okay, that makes sense. There are two possible approaches we could take, one would be creating some kind of E2E testing that would detect overflows/things like that, or integrating into existing tests, but that would probably require a lot of work for people. The other thing is, like Burj (Brendan) mentioned, integrating with PostHog session replays and the like and detecting overflows from there. Probably leaning towards the latter just for ease of use.
Yup, we use a very similar library on the backend, we just layer a few things on top of it, like our VSCode extension that scans through the app and auto-wraps user-facing strings for translation, build-time translation, automatic context, etc.
If you've got a big codebase, the VSCode extension can be super helpful for setting up.
I'm gonna be building a web app in the next month or so that's gonna need a ton of translation, but it's gonna be a SvelteKit app. Do you plan on supporting Svelte anytime soon?
Quetzal as a product is inevitable. It will make it even easier to target international markets from day one with a tiny team. Congrats on the launch! You rock! Greetings from section 4D!
Which language? Our site/dashboard supports 15 or so languages, as do our accessory apps/tools. Still working on our docs though, which are only in 2 languages...
It's a huge pet peeve of mine when translation services aren't themselves fully translated, and I see it a surprising amount ahaha
It should switch to the appropriate language based on your browser settings. If you're in Chrome, make sure that in Settings > Languages, your language is at the top of the list.
I honestly don't get the need for an LLM here, the landing page translations feels unnatural and there are some translations that don't really work in the context - how does this actually perform better than DeepL for instance?
No pricing to be found in the header for an AI product (which you'd expect to be on the pricier side) isn't great either.
Which translations feel unnatural at the moment so we can check into it? Right now we're still figuring out pricing, so everything is free at the moment in our pilot stage.
- "oder siehe So funktioniert es" should be worded differently, it seems to be two different strings
- "Ingenieure Zeichenketten in Schalter einwickeln" (From about page - I guess Zeichenketten is supposed to mean strings, which I think is more natural just leaving it untranslated, the sentence literally translates to "engineers embed strings/text into switches")
- the translated texts have quite long and complicated sentences, which feel unnatural (for example in the subtitle)
About pricing: I get it's early, though I think it'd probably be useful for users to have an idea of how much it might cost in the future, if they actually want to use it in a project.
The navigation also seems to overlap with the title on Chrome (latest Android)
The idea of parsing source code to auto inject translations, especially while leveraging machine translations comes up every 2 months.
It’s not solving the problem.
The problem to be solved is change control. Doing translations is (surprise!) cheap compared to controlling changes. Changes referring to the marketing copy changed, the button label changed, a new screen has been added, etc. It needs one system that can track and control changes across apps, translations, files.
If change control is solved, localization boils down to managing CI/CD pipelines.
I think that ideally, every project would be setup from scratch in the beginning to use t() tags or something similar to have translation keys so that setting up translations is as easy as swapping out what t() returns (from e.g. a config file or the like).
Of course, we all know that this is very rarely how projects end up getting setup especially in the early stages, and then it's just massive amounts of work to go back and set it up later.
The thing that's the most intriguing to me about what you're describing is automatically setting up translations in the build step where you auto-detect strings to translate. But looking at the site, most of it seems to be focused around the VSCode extension which will just sort of find and replace strings in the source code with t() tags.
Can you talk more about the translations in the build step? Is there a reason you're not talking more about that on the site? (Is it just newer, not very reliable/good, or...)?
The idea that I could just throw something like this into my project, not have t() tags in my source code but still get translations, sounds like magic and I think it would be really neat.
Yeah, we've noticed that companies in the early stage ignore i10n completely and then eventually realize it's going to be a huge lift to retroactively support it
So, for the build time translation-
Yeah, I would say it's not reliable yet =p
But, it's not that far off. It's not magic- the idea is that we inject the t functions at build time so that they don't need to be in your code. The vscode extension is a good visual for this- for many patterns, it correctly notices what does or doesn't need to be translated.
But, the real problem is that if a process like this goes awry (a strange pattern leads to text being erroneously translated/untranslated) then it is next to impossible for someone to debug.
Glad you think this is cool. We think this is absolutely on the horizon, and we hope to be the first to get people using it... but in the meantime, we don't want to be responsible for issues on prod...
> companies in the early stage ignore i10n completely and then eventually realize it's going to be a huge lift to retroactively support it
That's the correct thing to do. When you're first building a product you're trying to prove that it can and should exist: that you can get people to pay you money for it. It doesn't make sense to spend your time or money doing anything else.
Once you're successful then you know that people in one country like your product and maybe people in another company will as well. But until you know that, that's the only thing you should be working on.
Yes! I've seen multiple products that were only in English, translations were a super annoying productivity blocker (build step required), tens of unused string keys, keys not matching the it's content etc. Please don't localize until the product is at least 95% "finished".
On this, I just want to share my take-away from my translation engineering days: I fully believe the "right way to do it" is to have two string types: A regular string type and a "user-visible string" type, in a similar way that some frameworks expose a "safe string" vs "unsafe string" (for escaping purposes).
User-visible strings are consistently translatable, and the translation mechanism needs to have deep access in the language for this. I think in typescript this is a fairly doable thing given the AST access you yourself make use of. I'll gladly dig into how you do this on your end but I'm guessing it's somewhere along those lines but not quite?
Incidentally, when you have two string types, it becomes fairly straightforward to detect strings that probably should be translated but aren't tagged as such. Most strings are like this, in fact, because string constants tend to be a bad idea in general (vs numeric constants), and string operations tend to be a bad idea in the context of i18n (you want to use templated strings instead). So you tag until you only have a few left-over.
Yeah, this tracks! The steps are basically 1) determine user facing elements 2) determine strings 3) map user facing elements to the string. (We use the ast and no llms for this)
The upside of this approach is that we get a lot of context for accurate translation. The other upside is that down the line we can pull off fully automatic translation, but as others have pointed out, this is more of a gimmick. We think it's cool but it's more like the cherry on top
Also, yeah, that pattern would make life infinitely easier. Most develors really should think like this already, and not mix user facing strings with strings for other logic. But from what ive seen, pre i18n, devs dont think like this. Someday...
Interesting approach! I like the idea of using an ast to find translation strings and to generate source strings by an llm from the context. My experience is the same. Having to deal with 6 languages and a fast changing application is impossible for small teams, so I ended up with asimilar approach where developers only edit the source text, and target translations are automatically kept in sync using Deepl. This solves the whole i18n dilemma of outdated/missing translations, by just focussing on the source texts. It would be great to be able to even generate the source texts from the $t tag. I'm slowly turning this into an open source developer tool: https://garage44.org/posts/expressio/expressio-machine-trans...
This is a great idea. I have even hit this pain point when developing a healthcare app for hospitals that was primarily used in the United States. There are certain communities, even just within California, where it is common to have patients who only understand Spanish, Mandarin, or Japanese.
Any plans to extend this to iOS/Android development in the future? I assume it would already be easy to integrate this into React Native.
Also, is there a way for me to provide explicit additional context to the `t` function for the translation? Essentially a string that is appended to the LLM input for translation. For example, in Japanese there is often a significant difference between formal and informal language, and it is common to add post-positional particles such as や, が, and の to make titles and labels sound more natural. I see you have addressed many other special cases around numbers/dates/etc, so certain flags like formal/informal, regional dialect, etc may be valuable future additions.
Overall looks really nice and I look forward to trying this the next time the need arises.
Right now we actually do have React Native support, it is now in our docs! As for adding manual context, we're planning on adding that, but we don't want people to go overboard with adding additional context where it's not needed. We want to have suggestions for if we need additional context beyond what we get from the tree traversal. Also, in terms of tone/regional dialect, that's something we're adding into the dashboard so that all translations will have that info passed to the LLM to maintain consistency throughout the app!
I have been using a very similar approach for i18n of my eternally experimental web game https://luduxia.com/reversi/ which has an entertaining build process including this sort of thing. (I come from a game publishing background so have nightmares of when we all sent Excel sheets around motivating these things).
Does your result live update the strings in place if the device locale is changed?
Do you have any method for getting feedback from UI tests? I don’t now, but that is absolutely a feature I was used to previously. We used to OCR off expected areas to ensure things fit etc.
The computer kicked my ass. I had forgotten why I disliked othello...
As for the UI/UX tests, we're looking to integrate with PostHog and work with another company in our batch (PathPilot) which focus on analyzing user experience
Once we work these analytics in, the theory is we can better predict UI issues and resolve them retroactively. A full UI testing suite is something people have asked for, and we aren't there yet, but the tools are here
Yeah, we detect off the browser what locale we should switch into. As for UI tests, we're doing that ad-hoc right now for everybody, but what was your favorite approach to that? I'd love to look into what the best ways people handled that in the past and how we can improve on it
This was for video games (console, pc, mobile) but we had a framework where a video feed went into a host machine and you could get it to ocr read areas off the screen. This was then used to guide user input (i.e. find the right button if it had been moved) but also had checks for if strings exceeded bounding dimensions.
The classic always used to be German overflows, but these days the wrong sort of Chinese and RTL is more of a headache. (I have been ignoring proper RTL for a while).
I have also noticed LLMs get stuck in healthy/unhealthy loops when doing this sort of work. If you can snapshot the state of them when they are doing the right thing it would be very useful. They also build a lot of good per app context which improves the result quality.
Ahh okay, that makes sense. There are two possible approaches we could take, one would be creating some kind of E2E testing that would detect overflows/things like that, or integrating into existing tests, but that would probably require a lot of work for people. The other thing is, like Burj (Brendan) mentioned, integrating with PostHog session replays and the like and detecting overflows from there. Probably leaning towards the latter just for ease of use.
What measures have you taken to prevent things like this https://github.com/microsoft/WSL/issues/7868
for nextjs apps, localization with next-i18next was a breeze.
https://github.com/i18next/next-i18next
Yup, we use a very similar library on the backend, we just layer a few things on top of it, like our VSCode extension that scans through the app and auto-wraps user-facing strings for translation, build-time translation, automatic context, etc.
If you've got a big codebase, the VSCode extension can be super helpful for setting up.
Is your product essentially the VSCode extension? I’ll check it out
Would be cool to see the Quetzal website internationalized itself and see what it looks like in different languages.
We do have it translated into 13 languages right now, which language is your browser set to so we can add it?
I was also looking for that
I'm gonna be building a web app in the next month or so that's gonna need a ton of translation, but it's gonna be a SvelteKit app. Do you plan on supporting Svelte anytime soon?
Svelte should be supported soon, alongside the other major js frameworks we don't support yet. I hope it's ready in time for what you're building!
Quetzal as a product is inevitable. It will make it even easier to target international markets from day one with a tiny team. Congrats on the launch! You rock! Greetings from section 4D!
Maybe it doesn't recognize my language settings but it'd be nice if your website would be in my local language to show off that it works.
Which language? Our site/dashboard supports 15 or so languages, as do our accessory apps/tools. Still working on our docs though, which are only in 2 languages...
It's a huge pet peeve of mine when translation services aren't themselves fully translated, and I see it a surprising amount ahaha
It should switch to the appropriate language based on your browser settings. If you're in Chrome, make sure that in Settings > Languages, your language is at the top of the list.
Maybe there's just no Dutch translation? I just put it at the top. Restarted Chrome but the page is still in English.
Funny I have a domain very similarly named been always debating on developing, quetal.com. Otherwise cool concept
Very nice. Is vue supported?
Vue tooling should be ready soon, but it's not supported yet. All major js frameworks are high up on the roadmap
I honestly don't get the need for an LLM here, the landing page translations feels unnatural and there are some translations that don't really work in the context - how does this actually perform better than DeepL for instance?
No pricing to be found in the header for an AI product (which you'd expect to be on the pricier side) isn't great either.
Which translations feel unnatural at the moment so we can check into it? Right now we're still figuring out pricing, so everything is free at the moment in our pilot stage.
These are what I noticed:
- "oder siehe So funktioniert es" should be worded differently, it seems to be two different strings
- "Ingenieure Zeichenketten in Schalter einwickeln" (From about page - I guess Zeichenketten is supposed to mean strings, which I think is more natural just leaving it untranslated, the sentence literally translates to "engineers embed strings/text into switches")
- the translated texts have quite long and complicated sentences, which feel unnatural (for example in the subtitle)
About pricing: I get it's early, though I think it'd probably be useful for users to have an idea of how much it might cost in the future, if they actually want to use it in a project.
The navigation also seems to overlap with the title on Chrome (latest Android)
Congrats on launching. This looks promising
Just in time. Gonna try it right now. Will share feedback.
Hm. Not convincing. Disclaimer: I am the founder of Opral (https://inlang.com/ && https://lix.opral.com/)
The idea of parsing source code to auto inject translations, especially while leveraging machine translations comes up every 2 months.
It’s not solving the problem.
The problem to be solved is change control. Doing translations is (surprise!) cheap compared to controlling changes. Changes referring to the marketing copy changed, the button label changed, a new screen has been added, etc. It needs one system that can track and control changes across apps, translations, files.
If change control is solved, localization boils down to managing CI/CD pipelines.