Current interface language token (D8)

Some sample code was posted in #975116-30: Create a 'language' token type (D7) that might help whoever works on this.

This provides a partial port of the patch from the other issue. Right now it only supports 'langcode', 'name' and 'direction', the language object doesn't provide the other attributes without extra digging.

@DamienMcKenna i have applied the patch it is working fine and is adding language interface token.

The native name concept is gone, the domain and prefix are now in a separate config file, see language.negotiation.yml.

I don't quite understand the approach here. This defines separate types for interface and content language but those things are identical, it's just a language, the difference is where it comes from.

What if we'd tie this to the current-page token type, so you'd do something like [current-page:language-interface:name] ?

We only need a single language token type then with its tokens and two new tokens on the current-page type?

@Berdir: FYI I simply recreated the D7 patch so it would work on D8, no additional thought was put into how to make it work better.

Working on this.

Not working yet, not sure why, investigating.

This works, we also need to work in tests now. :)

This looks good but needs tests now.

See \Drupal\token\Tests\TokenMenuTest::testMultilingualMenu() for an example, we need to set up a set with at least two languages, then display those tokens somewhere and assert the displayed text.

\Drupal\Tests\token\Functional\UrlTest::testBlockUrlTokenReplacement() uses a block for that and tokens built-in token replacement functionality in that. So you can place a block that displays the language name, langcode and so on and then assert the strings on the page.

Hi! Not sure if it's the perfect place for that, but. Should be it useful to have more language aware tokens? Something like:

[current-page:url:LANG]
[site:url:LANG]
[node:url:LANG] or  [entity:url:LANG] or [entity:BUNDLE:url:LANG]

See this Metatag issue #2956982: Port hreflang tokens to D8

@raphaeltbm: What are those tokens supposed to return? Do you have a use case for that?
The current page language is very clear - it's the language in which the current page is rendered.
What's the "site language" for a site available in three languages? What's the "node language" for a node translated into three languages?

@ndlarge: My bad, i guess $options['langcode'] already allow to get the translated url for a node, entity, the current page or the frontpage, right?

Modules like Metatag have fields specifics to different languages, to manage alternate hreflang for example.
But i guess the issue is specific to Metatag here (and all the modules having this kind of implementation), these fields should be able to manage themself a token as [current-page:url] and set the langcode corresponding to their own language context, rather than set the current language by default. Before the tokenService replacement.

And so you should be able to do something like this:

alternate_hreflang_fr => [current-page:url]
alternate_hreflang_en => [current-page:url]

Better than this:

alternate_hreflang_fr  => [current-page:url:fr]
alternate_hreflang_en  => [current-page:url:en]

Well... I will post this problematic in Metatag issues.

Now working, thanks

I'm assuming that @yongt9412 is not actively working on it any more. I am assigning this to me to provide test coverage.

The patch under comment #11 still has the native name.
$replacements[$original] = $language->native;
As @Berdir stated the native name concept has been removed, so it should be removed from the patch as well.

By reading the tokens for me it makes more sense to do the following naming for the different contexts:

• language-interface -> interface-language
• language-content -> content-language

The common is the language itself, so the first part should refer to the specific element rather than starting with the common.
Like "current-page" in the token, or "current-user".

I added a test. The current implementation is failing on a few points:

• It tries to access properties such as $language->prefix and $language->domain which do not exist. This data is saved in configuration.
• The "base level" tokens such as [language:name] and [language:langcode] don't work on their own. Similar to the other tokens which are localized (such as date and url) we can fall back to the default language in the absence of any passed in language.
• The current implementation passes the langcode parameter in the $data array, but this should be passed in the $options array, as documented in Token::replace():

    /**
     * @param array $options
     *   (optional) A keyed array of settings and flags to control the token
     *   replacement process. Supported options are:
     *   - langcode: A language code to be used when generating locale-sensitive
     *     tokens.
     */
  

• An error occurs when a non-existing language is passed. We should check if the language exists before attempting to replace the token.

In this patch I have only added the test. These problems still need to be addressed.

This addresses the problems outlined in comment #20.

I will look to fix the comments from #18 and #19 now.

Addressed comments #18 and #19.

+++ b/tests/src/Kernel/LanguageTest.php
@@ -0,0 +1,367 @@
+  /**
+   * Tests the language tokens.
+   *
+   * @dataProvider languageTokenReplacementDataProvider
+   */
+  public function testLanguageTokenReplacement($token, $langcode, $expected_result) {

I still have very mixed feelings about data providers on kernel tests.

This doesn't really make it easier to understand for me and it's 10x slower. token.module has some assert helpers to assert a bunch of tokens and their expected value. Doesn't support cacheablity metadata, but asserted here either.

\Drupal\Tests\token\Kernel\NodeTest for example.

+1 for this, I just spent 20 minutes looking for the language token (a requirement for our implementations)

to fix

after
extra
patches

add this to your composer.json:

            "drupal/token": {
                "Add current language token.":
                "https://www.drupal.org/files/issues/2019-03-15/2863200-23.patch"
            },

alternatively, there is the token_language module. I haven't tried it yet.

For current language prefix
https://www.drupal.org/project/token_custom
current language prefix PHP:

$lang = \Drupal::languageManager()->getCurrentLanguage()->getId();
$languages_prefixes_arr = \Drupal::config('language.negotiation')->get('url.prefixes');
$language_prefix = ($languages_prefixes_arr[$lang]) ? $languages_prefixes_arr[$lang] . '/' : '';
return $language_prefix;

Hi!
I don't want to interfere with your excellent work here and hope the following helps.

I don't know if it is still time to add some more functional in the patch #23 ?
If yes, let me add it here, otherwise I can open a follow-up if better, just let me know.

Because we now have 'language' tokens, a very simple addition let those tokens exists for every entities. That means with the patch attached, it is possible to do new things like :

The follow displays the [node:language:name] version of a content originaly written in [node:source:language:name]
being output as:
The follow displays the English version of a content originaly written in French

I am adding also in the patch a simple change in NodeTest.php that demonstrate it working. Let me know if more test are needed.

> I still have very mixed feelings about data providers on kernel tests.

Apparently nobody wants to do something about my feelings here, fair enough. ;)

The entity token addition seems useful. Looks like this has quite a few followers and there has been no negative feedback on those patches, I wanted to commit it, but trying to run that language test locally gave me a segfault on PHP 7.4 in pcre2_jit_match_8 o.0. Lets see what Testbot has to say about different PHP versions.

Here is the patch rerolled so the tests can be triggered.

I tested it locally and didn't have problems with php 7.4 and 7.3

PHP 7.4 passes...

#29 works for me. Thanks!

Finally getting back to this, thanks for the reroll, committed.

Just searched for the language tokens in a project and found out that there's no stable release yet containing this important part (for metatags). Is a release planned containing this commit?

I'm confused: is this going to be ported to Drupal 9\does D9 include this somehow?
I've searched the code but I didn't find anything about language tokens, and the patch obviously doesn't apply for 9.2.x

This has been committed to the dev version of the Token module (8.x-1.x-dev), which can be used with Drupal 8 or 9. No 'proper' release of the module has been created since then, so you would either need to use that dev release, the patch, or wait for the next alpha/beta/rc/stable version of Token module.

Ok I see, thank you.

@Berdir , if you need assistance with creating a tagged release let us know maybe one of us can become a co-maintainer? It's been 7 months since this new token was committed in dev but it's still not in a tagged release.

feel free to assign me if you wish.

+1 for #38 - would be very helpful to have a new stable release :)

FYI, looks like this was included in the latest release: https://www.drupal.org/project/token/releases/8.x-1.10. Thanks!