Updated: Comment #N

Problem/Motivation

New supports either have no or the wrong language code on multilingual websites.

Proposed resolution

- Add a function that returns a language mapping between drupal and salsa, return variable_get('salsa_entity_language_mapping', array(...));
- This function could also live in salsa_api.
- Implement salsa_entity_salsa_supporter_presave($entity), check if Language_Code is empty, set it based on global $language and the mapping. Possibly optional (variable_get() check?)

Remaining tasks

User interface changes

API changes

New function.

Original report by @Berdir

Requires a mapping to all languages supporter by Salsa.

Comments

berdir’s picture

Issue summary: View changes
berdir’s picture

Note: #2108347: Adding Salsa-Translation support already added an initial mapping, although we might want to extend it here and make it configurable as suggested.

s_leu’s picture

Status: Active » Needs review
StatusFileSize
new3.8 KB

Alright here's a first patch. I also included a renaming of the wrong used ISO standards in the language mapper class.

s_leu’s picture

StatusFileSize
new3.86 KB

Added a variable_get as condition in the presave hook as proposed in the issue description.

berdir’s picture

+++ b/salsa_entity.module
@@ -232,6 +232,21 @@ function salsa_entity_salsa_object_type_info() {
+ */
+function salsa_entity_entity_presave($entity, $type) {
+  if ($type == 'salsa_supporter') {
+    global $language;
+    $lang_code = SalsaEntityLanguageMapper::toIso639_2();
+    $default_language = variable_get('language_default');
+    $entity->Language_Code = $lang_code ? $lang_code : SalsaEntityLanguageMapper::toIso639_2($default_language->language);
+  }

Should a) only change if the entity is new (no supporter_KEY) and Language_Code is currently empty. We don't want to affect code that re-saves supporters or sets the language code explicitly.

s_leu’s picture

Added another possibility to override language code mapping with custom variable and added the mentioned conditions in the presave hook.

s_leu’s picture

s_leu’s picture

Here the correct interdiff

s_leu’s picture

Found some more usages of the wrong iso code identifier in variable names and function docs. Also changed the @file description of the language mapper file.

s_leu’s picture

Found further occurrences of the wrong code...

s_leu’s picture

Added hidden field in single target action forms to provide supporter language there.

s_leu’s picture

Found that german had the wrong iso-639-2 code. Also removed unecessary passing of global language.

Status: Needs review » Needs work

The last submitted patch, 12: supporter-language-code-1924432-12.patch, failed testing.

LukyLuke_ch’s picture

The code looks good for me.

Due to the last change from 'deu' to 'ger' the test fails.
This should be corrected as well ;)

s_leu’s picture

Status: Needs work » Needs review
StatusFileSize
new1.52 KB
new9.42 KB

Didn't realize that there was a test for this. This patch was green on my machine.

LukyLuke_ch’s picture

Status: Needs review » Reviewed & tested by the community

Looks good now for me.

berdir’s picture

Status: Reviewed & tested by the community » Needs work
  1. +++ b/includes/salsa_entity.language_mapper.inc
    @@ -2,64 +2,73 @@
    -  protected static $code = array(
    -    'de' => 'deu',
    +  protected static $code_mapping = array(
    +    'de' => 'ger',
    

    Strange, how can this be working now for translations? I just confirmed and it is really ger.

  2. +++ b/salsa_entity.module
    @@ -232,6 +232,23 @@ function salsa_entity_salsa_object_type_info() {
    + */
    +function salsa_entity_entity_presave($entity, $type) {
    +  if ($type == 'salsa_supporter' && variable_get('salsa_entity_set_supporter_language', TRUE)) {
    +    // Set the code only for supporters that don't have any language code yet.
    

    You can also implement hook_salsa_supporter_presave() directly, saves you one check and doesn't invoke the hook when it's not necessary.

Given that this is pretty crucial and we want to make sure that it doesn't mess up existing data, can we add a basic test for this, you can test 3 scenarios:

a) Save a supporter with the setting disabled, shouldn't set a langcode.
b) Save a supporter with the setting enabled, should set the correct langcode (just making sure that the site default is set is enough, we don't need to test multiple languages)
c) Save a supporter that already has a langcode set and setting enabled, must not overwrite the existing value.

You can do this by testing the API directly, create supporter entities and save them.

s_leu’s picture

Status: Needs work » Needs review
StatusFileSize
new14.37 KB
new5.9 KB

Ok i applied to proposed improvements including the demanded test.

berdir’s picture

Status: Needs review » Fixed

Comitted.

  • Berdir committed 0bfc69c on 7.x-1.x authored by s_leu
    Issue #1924432 by s_leu: Default Language_Code for new supporters to...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.