Live data from Hacker News

Show HN: Tolgee – All-in-one localization for your project

tolgee.io

1–10 of 10 posts

Re: Show HN: Tolgee – All-in-one localization for your project

#2
It looks like this tool applies translations at runtime via an API call. While that probably makes integrations easy for people who are mostly adding site functionality with things like Google Tag Manager, that strikes me as a poor design decision for anyone with any more control over their site.

Re: Show HN: Tolgee – All-in-one localization for your project

#3

It looks like this tool applies translations at runtime via an API call. While that probably makes integrations easy for people who are mostly adding site functionality with things like Google Tag Manager, that strikes me as a poor design decision for anyone with any more control over their site.

Not sure I get that comment. I think the API first design is good. It let's you decouple the translations from your application.

It's then up to you too either do that on the server, on the client, or at build time. All three are easily possible. If you'd start with a static file then the decoupling and automation tasks will be much more difficult to achieve.

Re: Show HN: Tolgee – All-in-one localization for your project

#4
This looks interesting. I've been a globalization architect for ~5-6 years and have used many of the major TMS vendors (and developed my own for internal use).

I see you have support for ICU Message Format. What does the UI look like for a complex ICU string? A big issue I come across is that translators aren't typically technical enough to understand the syntax.

I've dreamed of a TMS that understands an incoming ICU Message Format and spits out a non-technical UI for translators to use. Then after translation it merges it all back together into a single ICU Message string.

Re: Show HN: Tolgee – All-in-one localization for your project

#5

It looks like this tool applies translations at runtime via an API call. While that probably makes integrations easy for people who are mostly adding site functionality with things like Google Tag Manager, that strikes me as a poor design decision for anyone with any more control over their site.

It's almost universally bad practice to reference your TMS at runtime. There are always exceptions in G11N, but typically the best route is to either dump your translations into a property file or cache the translations somehow (in memory or in a DB, etc)

Re: Show HN: Tolgee – All-in-one localization for your project

#8

Another question: what type of placeholders / tokens does this support? I see ICU Message Format, but what about `%d` or `%s` type placeholders

Hello, we decided to support just ICU format. We develop our own SDKs to support the in-context translating and we would like our users to use these. We are currently not targeting on users working with other i18n libs, so we don't support it. But yeah, in the future, we want to provide support also for this printf-ish message format

Re: Show HN: Tolgee – All-in-one localization for your project

#9

It looks like this tool applies translations at runtime via an API call. While that probably makes integrations easy for people who are mostly adding site functionality with things like Google Tag Manager, that strikes me as a poor design decision for anyone with any more control over their site.

It's almost universally bad practice to reference your TMS at runtime. There are always exceptions in G11N, but typically the best route is to either dump your translations into a property file or cache the translations somehow (in memory or in a DB, etc)

If you use Tolgee, you should be using translations fetched from REST API in production. So you don't reference your TMS. See: https://tolgee.io/docs/web/get_started/preparing_for_product...

Or: https://tolgee.io/docs/web/using_with_react/react_preparing_...