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

41–48 of 48 posts

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

#41

Post by betimsl »

I have a small framework I built for developing small web apps faster and it also has a translation engine very much like this, basically what it does is:

    $T(Detajet e blerësit)
and it translates it to:

    buf.WriteString(T(`Detajet e blerësit`))
T is a function that takes a string and returns a string from static map that gets built when app starts or when somebody translates a label.

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

#42

Post by abhisiv »

betimsl wrote: post #41

I have a small framework I built for developing small web apps faster and it also has a translation engine very much like this, basically what it does is: $T(Detajet e blerësit) and it translates it to: buf.WriteString(T(`Detajet e blerësit`)) T is a function that takes a string and returns a string from static map that gets built when app starts or when somebody translates a label.

Cool stuff! I would love to hear more about it. Please ping me at abhi@langapi.co if you want to talk.

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

#43

Post by mkycl »

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…

Mozilla’s Fluent project [1] seems like a really thoughtful and comprehensive approach to many of these problems.

[1] https://projectfluent.org/

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

#44

Post by scrollaway »

I worked on internationalization extensively before (Pootle, specifically).

The good:

The library's API seems pretty well-thought-out. A good i18n API in JS/TS is highly needed, even more so one that works well with React. I use i18next in my projects but it's mediocre, although I don't know that the difficulties I end up facing with it wouldn't show up here.

The bad:

Pricing. Sorry but translation services are extremely competitive, and players that have been around a long time such as Crowdin, Transifex and Weblate have the benefit of being already trusted by name by a huge community of devs and translators.

You also talk about open source a lot but I'm disappointed your web tooling doesn't seem to be open source & self-hostable. This is one point where you really could differenciate yourself.

The ugly:

It looks like you've pretty concretely tied your i18n API and your translation UI together. I can't see your UI or whether it's any good, but I'm likely to want to use your API with a different translation service, or your translation service with a different API.

Also, please, Google oauth is basically a requirement for any b2b service.

(I'm happy to give more thoughts on a video/screenshare chat if you like, feel free to reach out, email in my profile; always want to help new players in the i18n space)

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

#45

Post by polskibus »

abhisiv wrote: post #19
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!

As I mentioned - C#. Translation mechanism uses so called "resource" files with a master file (english), and secondary files with other languages.

see

https://docs.microsoft.com/en-us/windows/win32/intl/preparin...

for more information.

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

#46

Post by abhisiv »

mkycl wrote: post #43
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…

Mozilla’s Fluent project [1] seems like a really thoughtful and comprehensive approach to many of these problems. [1] https://projectfluent.org/

We analyzed fluent when we built the product and found that it didn't offer much more than the international standard ICU. Our platforms have full support for ICU syntax including plurals.

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

#47

Post by abhisiv »

AlchemistCamp wrote: post #40

I use gettext for whatever back-end language I'm using. I much prefer handling this sort of thing from the back-end. That way it doesn't matter what the front-end is. It just works.

For frameworks with gettext we integrate with it! Gettext will extract the phrases into a .po file but these need to be translated. Running 'langapi push' will push out all the .po files in the codebase and running 'langapi pull' will pull the translated versions back in and automatically save them in the correct locations.

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

#48

Post by abhisiv »

davidzweig wrote: post #36

We needed recently translate our chrome extension (languagelearningwithnetflix.com) into 18 languages. We are poor and had less than $1000 for the job. Here's our approach. 1. Move all strings into a Google doc. Takes about 8 hours. 2. Organise strings into groups with screenshots, think carefully, split strings, look for reused strings, reword things to make them simpler and easier to translate, add notes to some st…

Wow, that's very interesting--what a time consuming experience. You can imagine that this method would not be sustainable for larger codebases. Let me know at abhi@langapi.co next time you go through this process and we'll help you out :).
Post reply on HN