Live data from Hacker News

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

news.ycombinator.com

21–30 of 48 posts

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

#21

Very interesting, question: from the pricing page: it is unclear to me what is meant by phrases in the context "100 Phrases" for $99 plan?

That's great feedback -- we're still working on the best way to do pricing. A phrase is any text wrapped with our 'tr' function. We use phrases for pricing currently because it's an industry norm but we're open to changing it if it causes confusion.

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

#23

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…

1. We support both client and server side frameworks (Django, python, NodeJS). We're adding support for more as fast as we can including Java and Rails.

2. The 'translations.json' file is autogenerated by the CLI and updated each time you pull translations. It's automatically bundled in the deploy process so you don't need to do any extra work.

3. Currently we have a single translations.json file. Space hasn't been an issue yet but we plan to add splitting to reduce it. For dynamic content which can be large, we have solutions where we can serve the content as a CDN. We could also give clients a microservice if they would like to self-host or directly update a cache on disk on the deployed machines. Still experimenting with the best/easiest way to do this.

4. Sure thing, we have a file upload in our dashboard right now, but we want to add this to our CLI to make it more accessible.

I understand your frustration and one of our core philosophies is to do away with keys completely. Our keys are auto-generated and not touched by the user. The code can have the actual text which is a lot more readable. Ping me at abhi@langapi.co and I'd love to help solve your problems.

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

#27

Correct me if I'm wrong but wouldn't I still have to take the time to wrap everything in the codebase? I feel like that's the majority of the painful work.

Developers with large code bases have complained that it takes weeks to manually wrap all their strings. We have an experimental tool for ReactJS which can wrap all the front facing strings with our function instantly. It's currently in beta but we recently used it to onboard a codebase with over 1000 strings in half an hour. We're also looking to build this auto-wrapping service for other frameworks.

Ping me at abhi@langapi.co if you want a demo of this beta tool or if you want it for another framework.

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

#28

This looks great & hi Abhi! Will this support left script languages?

Hey! Requesting and receiving translations work with any language including left script (right-to-left) languages. In the future, we want to solve the page layout problem for RTL languages as we've seen it's a big pain point.

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

#30
post #21

Very interesting, question: from the pricing page: it is unclear to me what is meant by phrases in the context "100 Phrases" for $99 plan?

That's great feedback -- we're still working on the best way to do pricing. A phrase is any text wrapped with our 'tr' function. We use phrases for pricing currently because it's an industry norm but we're open to changing it if it causes confusion.

I think the confusion for me was that there is also a pay-per-word price; then for me the limit on the number of phrases does not feel logical. Phrases as tr() calls for me as a developer also depend quite a bit on how I have setup the translation and differ per project.

I would expect to pay a monthly fee for the online service + a fee for each word. Also, 100 unique tr()'s seem a bit limiting? (even smaller projects for me quickly get > 1000 separate tr calls)

Post reply on HN