full localization support

[peppelinux]

Hi guys, I'd going to translate healthchecks in italian. For doing it I'd have to put {% trans %} template tags in all the .html files. Are you interested in it? I'd push a pull request with this and also a italian localization regards

[cuu508]

Just to understand your use case, are you planning to use Healthchecks in a setting where there's a requirement that the software is localized? If you go through with the translation, would it be an one time thing, or would you be planning to maintain it (translate new and updated strings, test translations) long term?

There's a bunch of pros and cons and honestly I'm not sure what's the correct approach.

Setting the project up for translations is a fair bit of work. It is not only {% trans %} tags, there are strings also in Python and JS code. If we do it, I'd like to do the changes incrementally, not one big PR that changes pretty much all files in the project.

Having the {% trans %} tags, and gettext stuff in Python code adds some performance overhead, but more importantly it adds complexity and verbosity. It may may or may not be worth it, depending on how many people are going to use the non-English versions.

One project I sometimes look at to see "how others are doing it" is Sentry. Sentry does support translations, in "User Settings" the user can select their UI language. I tested German and Spanish, and in both cases maybe 20% of UI text changed, it was still mostly English. I would guess that the translations were "complete" at some point, but as the project evolved the translations didn't keep up. Sentry is much bigger project than Healthchecks, so my worry is that same thing would happen here.

[peppelinux]

Thank you @cuu508 for your reply, I often use django in my projects and I'm quite experienced with localization support. In my organization we really appreciate healthchecks and I want first of all spend this moment to thank you all for the wonderful work done, sincere congratulations.

We made a fork and we just localizaed menu voices (base.html) and welcome page, because this was needed in my organization. If we would create a branch for a full localization I can do the italian part, english will be the default one and don't need any translations, other languages would be merged as third contribution come, if come.

Probably only the welcome page and the menu voices could be localizaed, see our page here: https://healthchecks.unical.it set italian language in your browser (or install an addon to switch languages)

our repo is here: https://github.com/UniversitaDellaCalabria/healthchecks

I'd merge your latest commits and update the locale branch and then to a PR from this to the branch you will indicate to me, if interested. I also added SAML2 Support with djangosaml2 if you are interested in a native support of this in healthchecks.

Thank you again and continue do this way, it's awesome

[cuu508]

Thanks, glad to hear Healthchecks is useful for you!

OK, let's try and set the project up for localization, and see how it goes. As I mentioned earlier, I'd like to do this in steps. The base + welcome templates are a good first step.

Would you be able to prepare a PR with just the translations (no SAML stuff, and no branding tweaks)? I'm not opposed to SAML support in principle, but would like to deal with it separately.

Looking at the changes in your repo,

        <h1 class="text-center">{% trans "What Can I Monitor With" %} {% site_name %}?</h1>

We may want to look at blocktrans and using placeholders – if the placeholder is inside the string template, the translator can move it around in the sentence (I have minimal experience with translations & Django – maybe placeholders don't work as I imagine they do, or maybe there's a better way).

[peppelinux]

Here a cleaned PR that do this, I didn't use blocktrans but the big work is already done and I think that would be trivial switch from trans to blocktrans:

https://github.com/healthchecks/healthchecks/pull/405#issuecomment-661768064

[cuu508]

Thanks for the updated PR! I started to work through switching to blocktrans tags, there's actually a fair bit of work in there...

I see you have split up sentences like:

{% trans "Down." %}
{% trans "Time since last ping has exceeded " %}<strong>Period</strong> + <strong>Grace</strong>.
{% trans 'When check goes from "Late" to "Down"' %}, {% site_name %}
{% trans "sends you a notification." %}

What's your opinion on doing this instead:

{% blocktrans trimmed %}
Down. Time since last ping has exceeded <strong>Period</strong> + <strong>Grace</strong>.
When check goes from "Late" to "Down", {{ site_name }} sends you a notification.
{% endblocktrans %}

A downside to this is – the translator gets to see <strong> tags in the strings. But, on the upside, sentences are not chopped up, so the translator sees more context when translating, and also has some freedom to change the sentence structure.

I noticed a few different small issues with the PR:

• there's a merge conflict in there (look for >>>>>>>, <<<<<<<< delimiters)
• you've commented out the email example – that's an unrelated change
• double quotes changed to single quotes in this string:

Grace Time specifies how "late" a ping can be before you will be alerted.

Instead of massaging this PR into shape, how about we do the following:

• I change the current master version to use {{ site_name }} (which will come from template context processor) instead of {% site_name %}. I then annotate the welcome and base templates in the current master with trans and blocktrans tags
• You update the Italian translation – some translations will be fuzzy or invalid because of conversion to blocktrans tags

How does that sound?

[peppelinux]

I think that sounds good, I used single statements because in large projects it helps me to reuse words and translations but yes, blocktrans would be the right choices here.

very sorry for the missing delimiters, I did it in a hurry! Yes, commented out email example for my users, my fault. No problem if double or single quotes for me.

No problem for fuzziness, it's in my habit. Ok, I close that PR and then moving to another one with italian localization. thank you

[peppelinux]

Just cite this issue in your following commits, where localization support will be enabled. I'll check here for citations and then merge from your master to my fork and refactor the it locale. cheers

[cuu508]

I did the base and welcome templates, and added Latvian translations (Latvian is my native language) to test how they work.

[peppelinux]

Ok, I'll do my part. Thank you for endorsment and "ad maiora"

[luponata]

Hello, we started using HC from version 2.7

From what I can see, the Italian localization was done only on some object (Docs and Integrations buttons on the top bar for example)

Unfortunately it seems not possible to manually choose the English language to avoid this ambiguity, because the application performs the automatic localization knowing the language of my browser

Any tips ?

Speaking for me, I'm not interested in the Italian translation, but if there is one, it would be better if it were done properly, without leaving half of the interface in English (thinking about the others)

[cuu508]

We experimentally added localization support (and translations in German, French, Italian, Latvian) for the "welcome" page. With the idea being to test the L10N infrastructure, and continue on with adding L10N support in other pages if there is interest.

I later removed the welcome page, leaving us in the situation where only a few strings in the top navigation are localized.

I'm planning to remove localization support completely. My thinking is:

• There's only point to have translated UI, if it is done fully, and the translations are high quality. This requires a bunch of effort, and help from volunteers. Both for the initial translations, and for maintenance, when UI strings get added or changed.
• Healthchecks is a technical product with a technical audience. I think the majority of users would prefer to use it in English anyway.

[luponata]

I agree, in fact, the level of English necessary to understand the webapp is not high, where at worst they can always use the translator