Since languages both have a name and language code? This is not a huge priority.

CommentFileSizeAuthor
#11 languagetoken-975116-6.patch4.35 KBpobster
PASSED: [[SimpleTest]]: [MySQL] 347 pass(es). View
#8 languagetoken-975116-5.patch4.46 KBpobster
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in languagetoken-975116-5_0.patch. View
#6 languagetoken-975116-5.patch4.44 KBpobster
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in languagetoken-975116-5.patch. View
#4 language-token-975116-4.patch4.39 KBpobster
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in language-token-975116-4.patch. View
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

vasike’s picture

subscribe. good to have the language object "translated" to tokens

colan’s picture

Category: task » feature

I'm assuming that this includes tokens for both the content language and the interface language? #233076: Add token for node's language only works for nodes, but these tokens should be available everywhere.

A use case is setting the Dublin Core language metatag to something like this:
<meta name="dcterms.language" content="eng">

The setting for that should come from a token. How about these:

  • [site:language:content:name]
  • [site:language:content:code]
  • [site:language:interface:name]
  • [site:language:interface:code]

...which would come from:

matsbla’s picture

These would be very practical!

pobster’s picture

Status: Active » Needs review
FileSize
4.39 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in language-token-975116-4.patch. View

I gave it a go...

Thanks,

Pobster

Status: Needs review » Needs work

The last submitted patch, language-token-975116-4.patch, failed testing.

pobster’s picture

Status: Needs work » Needs review
FileSize
4.44 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in languagetoken-975116-5.patch. View

Hmmm filename fail - good job anyway as I used language instead of language_content for the replacement...

Thanks,

Pobster

Status: Needs review » Needs work

The last submitted patch, languagetoken-975116-5.patch, failed testing.

pobster’s picture

Status: Needs work » Needs review
FileSize
4.46 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in languagetoken-975116-5_0.patch. View

Ummm on Linux, using git... Tried cleaning the line endings manually - this suggests the token.tokens.inc file has bad line endings (I use preserve).

Thanks,

Pobster

Status: Needs review » Needs work

The last submitted patch, languagetoken-975116-5.patch, failed testing.

pobster’s picture

Okay I give up, I haven't got time to mess around with this right now. I'll do it later from home, it's hardly a massive change anyway - maybe I'll add to the simpletests as well.

Pobster

pobster’s picture

Status: Needs work » Needs review
FileSize
4.35 KB
PASSED: [[SimpleTest]]: [MySQL] 347 pass(es). View

Fixed typo.

Pobster

mareks’s picture

I think that the last patch works. I was actually surprised that Token did not have Current UI language before :)

rondev’s picture

I tested it with https://drupal.org/project/metatag
Seems OK.
I use [language:language-content] for content language in the Global section of Metatag.

DamienMcKenna’s picture

Out of interest, would it be worth adding another token to list all of the supported languages for the site?

pobster’s picture

Issue summary: View changes

I believe it does that if you just choose the parent (can't actually remember, it's been a while since I did this).

Thanks,

Pobster

lpalgarvio’s picture

Status: Needs review » Reviewed & tested by the community

works great!

please commit

liquidcms’s picture

can anyone give a hint as to what the actual token would be for this?

i am trying to use Display Suite to create a custom field and when i open the token browser to display aprox 200M of tokens, the only one i can find related to language is [node:language] and this only gives the lang code.

liquidcms’s picture

nope, my bad.. i didn't read close enough and assumed 4 yrs into D7 this had been committed.. so applied patch and now i see the tokens in the token browser; but [language-content:name] does not output anything.

liquidcms’s picture

for anyone else looking for a solution for this, since the above patch didnt work, i just wrote my own token:

function mymodule_token_info() {
  $info['tokens']['node']['language-name'] = array(
    'name' => t('Language'),
    'description' => t('The language name the current node is in.'),
  );
  return $info;
}

function mymodule_tokens($type, $tokens, array $data = array(), array $options = array()) {
  $replacements = array();
  
  if ($type == 'node' && !empty($data['node'])) {
    $node = $data['node'];
    foreach ($tokens as $name => $original) {
      switch ($name) {
        case 'language-name':
          $replacements[$original] = locale_language_name($node->language);
          break;
      }
    }
  } 

  return $replacements;
}
pobster’s picture

Odd, I tested the patch today and it applied fine for me?

liquidcms’s picture

patch applied fine.. but outputs nothing. possibly since you have it declared as type = language; does this mean it won't be usable in a node context? i have mine as type 'node' so it shows within node context; perhaps it should be global though?

pintoflager’s picture

Applied patch to 7.x-1.6 today and both UI language and content language worked just fine.

Would be great to get this committed.

My use case was pre-defining a language facet to a currently active language when going to search-page from a menu item.

Like this:
http://www.example.com/EN/search-all/lang-facet/EN

Now search results are pre-defined to users current language and he/she is still able to extend the search to other languages from facet if needed.

Noe_’s picture

Just tried it and it works flawlessly.

Jelle_S’s picture

Patch still applies and works like a charm. I can't see any downsides to it, or any reason why this shouldn't be added. It would be great if this got committed!

DamienMcKenna’s picture

Bump to see if Dave Reid might be able to provide some insight on what blockers, if any, exist to getting this committed.

pobster’s picture

Well I'm just glad that people are finding it useful, that's great! :o)

Thanks,

Pobster

mariano.barcia’s picture

+1 to get this committed.
I'm using this patch in PROD.
Thanks very much in advance.

phKU’s picture

Site wide language code by module implementation, forked from liquidcms, thanks!
Caution: this is D8 version. For D7, please change '\Drupal::languageManager()->getCurrentLanguage()->getId()' to 'i18n_get_lang()'

function mymodule_token_info() {
  $info['tokens']['site']['language-code'] = array(
    'name' => t('Language code'),
    'description' => t('The curremt language code.'),
  );

  return $info;
}

function mymodule_tokens($type, $tokens, $data = array(), $options = array()) {
  $replacements = array();
  
  if ($type == 'site') {
    foreach ($tokens as $name => $original) {
      if ($name == "language-code") {
        $replacements[$original] = \Drupal::languageManager()->getCurrentLanguage()->getId();
      }
    }
  } 

  return $replacements;
}
ndlarge’s picture

Not sure the current language token(s) belong in the "site:" section. The "site:" token group includes stuff which is invariant across the whole site but current language isn't. The current language is not site-specific, it's page-specific. With a multilingual web site (probably the only use case where these tokens are even needed in the first place), pages can be rendered in different languages and every instance of a rendered page can only have one currentLanguage.
I vote for
[current-page:language:code]
and
[current-page:language:name]