Please add a field for html iso language code to language pages

BernhardBaumrock commented 11 months ago

Short description of the enhancement

ProcessWire has great language support and we have great flexibility. Sometimes this flexibility makes us do the same things over and over again.

Every HTML page has the <html lang="en"> tag at the very top of the page. Unfortunately it is not so easy to populate this tag in the markup. You might have come up with something like this:

<?php
$lang = "en";
if($user->language->name == 'german') $lang = "de";
elseif(...) $lang = "fr";
echo "<html lang='$lang'>";

Current vs. suggested behavior

I think it would be nice to have a dedicated field for that in the language editor:

Then we could have simple markup like this:

<html lang="<?= $user->language->code ?>">

Why would the enhancement be useful to users?

This would not only reduce the amount of code needed on the frontend but also make it possible to ship modules with translation files based on a standardised language code for example when using the RockLanguage module.

We could then ship modules with translation files in the "DE" folder and PW could automatically grab those translations because it instantly knows which language they belong to.

Thx in advance!

PS: Here is the hook that I used for the screenshot:

$wire->addHookAfter("ProcessPageEdit::buildForm", function ($e) {
  $form = $e->return;

  $f = new InputfieldText();
  $f->label = "Language ISO Code";
  $f->notes = "Can be used for the <html lang=...> root element."
    . " See [here](https://www.w3schools.com/tags/ref_language_codes.asp) for a list of all codes.";

  $form->insertAfter($f, $form->get('title'));
});

teppokoivula commented 11 months ago

Makes sense 🙂

Just for the record, all our sites have a language_code field added to the language template for this purpose. This comes from the template for new sites, so we don't need to do it for new sites manually.

Only thing I'm wondering is that how would this addition work for existing sites? For it to be reliably available it would likely need to be a non-field of some sort, e.g. method and hook based rather than real field? With value stored in page meta?

The easy solution would be to just add it to the default site profile(s), but that would mean that it's not reliably available on existing sites, which seems to defeat the purpose. At least to certain extent. If the point is to have it always available, then it not being available on older/updated sites would be a bit of a bummer.

Also, loosely related but adding new reserved field names is likely to break existing sites, so hopefully that is not needed (last I checked PW didn't handle such a case gracefully, had a few sites break due to this while updating from 2.x to 3.x).

adrianbj commented 11 months ago

I've always added iso and iso_long fields to the language template because you can match locale_accept_from_http($_SERVER['HTTP_ACCEPT_LANGUAGE']) to the iso_long and if you ever need to send text out for translation you'll want the long code as well.

BernhardBaumrock commented 11 months ago

@adrianbj do you have a link for the iso_long codes you are talking about?

Here is one for the short codes: https://www.w3schools.com/tags/ref_language_codes.asp

adrianbj commented 11 months ago

@BernhardBaumrock - this one includes both: http://www.lingoes.net/en/translator/langcode.htm

BernhardBaumrock commented 11 months ago

Wouldn't it then be even better to have a select box to choose from one of the options? I don't think this list is changing any time soon?

ryancramerdesign commented 4 months ago

I almost always use the language page name for the language ISO code. It doesn't work for the default language though, so you can do something like this:

$langCode = $user->language->isDefault() ? 'en' : $user->language->name;

BernhardBaumrock commented 4 months ago

Hey @ryancramerdesign I know it's easy to do, but the bigger (huge) benefit would be that we have a standardised way of how to ship modules with translation files.

My main language is German, so all my modules exist with German translations. I put all the translations fully automated in /site/modules/MyModule/RockLanguage/DE/...

The only part missing to automate that setup is that we have the language code of the language available as a setting of every language!

This is what I have to do on every RockLanguage installation (or possibly anyone using RockLanguage):

Please take the time and see that config screen. Would you know what to put in the language mappings field?

No? Great! That shows it's too complicated :)

The mapping for this site would be default=DE

On the other hand it's trivial for a user to input a field that says 2-letter code of the language.

Also I had to build the logic and config for these language mappings, which would not have been necessary if we had the language-code available from $language->iso or whatever.

And every other module developer working with processwire languages faces the same problems, as we have no unified process to identify languages across projects and across modules...

BernhardBaumrock commented 4 months ago

PS: see https://github.com/baumrock/rocklanguage if you are interested

processwire / processwire-requests