abhisiv

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 :).

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.

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.

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

Our framework automatically checks the browser language preferences. Change your browser language preference to Spanish and refresh to see the translations. We'll also add the flag toggler soon to make it more obvious.

Our site is internationalized with our product and we have Spanish translations. If you change your Chrome language setting to Spanish you can see it. We'll plan to add a manual language flag soon.

Good question, we let you provide as much context to the translators as you want (description, tone, and screenshots). If you still don't like the translation, you can comment and it will be redone taking your comment into account. Additionally, if you have employees who want to review the translations, they can do that on the platform.

We currently handle plan to handle localization of text (regular, dates, currency, time, gender, plurals, etc.). Handling images is interesting though, I would love to explore that more if it was a pain point for you. Ping me at abhi@langapi.co--I'd love to talk!

Our tools send the strings to a dashboard. At this point, you can have your own translators add translations and pull them back in. We have developed flows which make it easy for your own translators to go through your phrases, see the context (description + screenshots) and add appropriate translations.

Sending translations to the agencies we've partnered with is completely optional.

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.

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.

Thanks :)

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.

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.

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!

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!