[HN Gopher] Launch HN: Quetzal (YC S24) - Stripe for Internation...
___________________________________________________________________
Launch HN: Quetzal (YC S24) - Stripe for Internationalization
Hi hackers, John and Brendan here from Quetzal
(https://getquetzal.com) We're trying to make it as easy as
possible to translate software into other languages using LLMs.
Here's a demo: https://www.youtube.com/watch?v=8hUltBUk9sE.
Internationalizing/localizing is hard. You have to comb through
your whole app and look for what needs to be translated and
manually update your translations every time new stuff gets added.
People sometimes hire their own in-house translators, or they send
off their translations to humans to be translated, which takes
days, weeks, or worse and costs a ton. Internationalization is, of
course, super important for user growth and retention, and often
neglected until very late, when competitors will make your product
for LATAM, APAC, or Europe. I worked at Slack for three years on
the Slack Connect team, building features like Shared Channels and
Shared Workspaces, which had millions of users all over the world.
Our translation system was slow and painful, often delaying product
launches when things were added last-minute, and resulted in
context-less and inconsistent translations. Words like "duplicate"
could be either an action or a state, depending on if it's in a
button or just displaying a status, and words like "Huddles" were
translated ten different ways by translators who just wanted to get
through as many translations as possible as quickly as possible,
hindering adoption and confusing users. In a parallel universe,
but in the same Downtown Oakland apartment, Brendan worked at a
retail startup from the founder of Woot, acquired by Amazon, and
they brought someone in to manually translate their product into
Spanish, which was expensive and took months. Even worse, the
translations had to be manually ported over by engineers every time
they updated. Brendan and I have been coding together since fourth
grade, starting by making Cydia tweaks on iOS 4, building apps like
one of the first Dogecoin wallets (DogeTicker) in ninth grade, and
running small businesses fixing computers and making websites. When
we realized we both had miserable translation experiences, we
decided to work together to make these approaches a thing of the
past! Our solution to these problems is multiple. Firstly, we
utilize a custom Babel plugin to traverse the AST and search for
user-facing strings that should be translated, eliminating the need
to manually comb through the application and gather strings. During
builds, we also utilize the AST to provide context to the LLMs on
any new text which is then used to give correct translations for
different use cases, (e.g. "Duplicate -- is it in a button, where
it's a verb, or is in a regular string, where it's a noun?) After
scanning for strings and wrapping them in functions to display
correct translations to the user based on their browser locale, we
gather these strings and build time, and submit new strings to be
translated and bring in recently translated strings. During
translation, we take both the context and similar strings to
guarantee consistency. Translation itself using our LLMs only takes
a few seconds, rather than days utilizing humans. Of course, we
check them afterwards, but LLMs were themselves built for
translation and semantic understanding, so they are incredibly good
at delivering context-rich, consistent, and great translations
better than humans are. What's great about this solution is that
translations are instant and excellent, and you don't have to spend
hundreds of hours finding what needs to be translated and passing
them off to an external team, you don't have to wait days for bad
quality translations, you don't have to maintain a bot to merge
completed translations into the codebase, and you don't have to
pass context yourself. We've got a pilot running on our site right
now, so if you've got a Next.js project, feel free to try it out
using the script on our homepage: https://getquetzal.com. If you've
got a project written in some other framework, like vanilla React
or React Native, reach out to us (founders@getquetzal.com), we've
got npm packages that support these too. If you'd like to see
support for something else entirely, like Swift, please let us know
and we'll move it up on our docket. Let me know what you all think
about how software translation is today. Is it hard? What
approaches have worked or not? We also want to explore problems
like how people reach new markets and find customers, so that's
something we're thinking a lot about as well. If you've got funny
bad translation stories, I'd love to hear those too, the more
shocking and hilarious the better.
Author : jthompson4004
Score : 34 points
Date : 2024-10-01 18:12 UTC (4 hours ago)
| sidcool wrote:
| Congrats on launching. This looks promising
| primitivesuave wrote:
| 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 ya, ga, and no 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.
| jthompson4004 wrote:
| 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!
| fakedang wrote:
| Just in time. Gonna try it right now. Will share feedback.
| fidotron wrote:
| 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.
| jthompson4004 wrote:
| 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
| fidotron wrote:
| 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.
| jthompson4004 wrote:
| 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.
| Burj wrote:
| 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
| nextworddev wrote:
| for nextjs apps, localization with next-i18next was a breeze.
|
| https://github.com/i18next/next-i18next
| jthompson4004 wrote:
| 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.
| nextworddev wrote:
| Is your product essentially the VSCode extension? I'll check
| it out
| silverlight wrote:
| 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.
| Burj wrote:
| 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...
| JanSt wrote:
| Very nice. Is vue supported?
| Burj wrote:
| Vue tooling should be ready soon, but it's not supported yet.
| All major js frameworks are high up on the roadmap
| ck_one wrote:
| 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!
| joshdavham wrote:
| 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?
| Burj wrote:
| 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!
| XetiNA wrote:
| 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.
| jthompson4004 wrote:
| 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.
| XetiNA wrote:
| Maybe there's just no Dutch translation? I just put it at the
| top. Restarted Chrome but the page is still in English.
| Burj wrote:
| 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
| cheeseblubber wrote:
| Would be cool to see the Quetzal website internationalized itself
| and see what it looks like in different languages.
| jenny91 wrote:
| I was also looking for that
| n_plus_1_acc wrote:
| What measures have you taken to prevent things like this
| https://github.com/microsoft/WSL/issues/7868
| samuelstros wrote:
| 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.
___________________________________________________________________
(page generated 2024-10-01 23:00 UTC)