Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Lang (YC S19) – Internationalization Built for Devs

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 48 posts

Re: Launch HN: Lang (YC S19) – Internationalization Built for Devs

#11

Post by jedberg »

smitop wrote: post #7

Couldn't a bad actor abuse liveTr() and call it with a ton of random strings to make me pay to translate a ton of garbage data?

Presumably you would have to build protections into your own app to prevent that, much like any other user input abuse.

Re: Launch HN: Lang (YC S19) – Internationalization Built for Devs

#14

Post by jedberg »

cyrieu wrote: post #8
jedberg wrote: post #5

This is very cool! It took us months to build the equivalent tooling for reddit (except we were using crowd sourced translations instead of machine based ones). Do your clients do local caching, or is my uptime dependent on your uptime (unless I code in my own caching I suppose)?

Great question, and thanks so much for sharing your experience at reddit! For static strings, we create resource files and download them directly into your codebase, so your uptime is totally independent of ours once you deploy your app. For dynamic strings in the database/generated by users, our servers need to be up to receive + handle the translation request, but that will be cached the next time you try to look t…

I'm glad to hear you guys put thought into reliability from the start!

Re: Launch HN: Lang (YC S19) – Internationalization Built for Devs

#15

Post by khalilravanna »

This looks super cool. I got a bunch of questions!

1. Am I correct in understanding this is meant as a client-side only solution for now? Right now we have a pretty complicated translations process that needs to support translations that are spread across the client and server. Would this support a hybrid approach like that?

2. Another question I have is where does the `translations.json` file come from and where is that stored? Is that just generated by the CLI and then we have to deal with serving that however we want?

3. Is there one `translations.json` file per language? One with all of them? Are there performance concerns with sending large files like that over to the client? This is a general question for me to other developers of large sites: how do you deal with tons of translations?

4. Any plans to support existing translations? E.g. if I have an existing set of translations keys and values can I plug those in somewhere? I know y'all are bootstrapping so it wouldn't surprise me if that's a Future feature.

Again, love the idea of this, and it would be super cool if this solves the problems due to complexity we currently have with supporting a ton of languages.

--

For some background our current solution involves a generating a rather large (> 1MB) `translations.json` file for each language that we serve to the client via a CDN. Typical map of keys to values.

We create the keys ourselves as we go along something like `dashboard.salesCard-helpText`. Then we have to kludgy Drupal instance to populate the key and value, add some tagging to show it needs to be translated. Translations get entered into that Drupal instance. All of this is entered manually. Then that gets used to generate the `translations.json` file I mentioned earlier.

We have plans in the future to overhaul the process.

Re: Launch HN: Lang (YC S19) – Internationalization Built for Devs

#17

Post by codingdave »

I like the idea, but you are putting more weight behind the tooling than I would. I don't find translation tooling to be cumbersome, so especially if machine translations are free, I don't find the price point for human translations to be compelling.

What would be compelling is if you could pro-actively call out the bigger gotchas in translation - grammatical differences that make you change word orders, different mechanism for handling plurals, etc. If you could preemptively warn us, even before a "push" that we may hit a problem, I'd take a closer look. For example, flagging a line saying, "Hey, it looks like you are using phrasing that will be problematic in Here's why..."

Re: Launch HN: Lang (YC S19) – Internationalization Built for Devs

#19

Post by abhisiv »

polskibus wrote: post #18

I'd love to see support for other server-side languages, like C# (preferably something that can blend in with existing resource files) and Java.

We're actually building out support for Java right now and would be more than happy to explore other server-side languages you're interested in. If you have more specific requests ping me at abhi@langapi.co and I'd love to talk!

Re: Launch HN: Lang (YC S19) – Internationalization Built for Devs

#20

Post by abhisiv »

codingdave wrote: post #17

I like the idea, but you are putting more weight behind the tooling than I would. I don't find translation tooling to be cumbersome, so especially if machine translations are free, I don't find the price point for human translations to be compelling. What would be compelling is if you could pro-actively call out the bigger gotchas in translation - grammatical differences that make you change word orders, different me…

Great point, we would like to add support for common gotchas. Right now we abstract all plural logic away from the user by automatically requesting all plural forms of a phrase for each language. We also have noticed that translations often break layouts so we are pushing a tool that notifies you when translations are x% longer or shorter than the original string.

We would love to explore more ways we could help pro-actively solve these problems. Ping me at abhi@langapi.co if you want to talk more!

Post reply on HN