fr-CA translation of COM_FABRIK_FAILED_VALIDATION will not work

[shawnmcginn]

Sorry for the delayed response I took some time off over the holidays. I'll update as recommended and let you know how I make out.
Note: I had to move away from SEF urls as I ran into some issues with redirects for different user types early on in development. After our next release I'll look into re-enabling sef for the application.
Thanks!
Shawn

 

[cheesegrits]

OK. I hope it works, as I've had to undo all the multi language stuff I set up on my test box, as it was getting in the way of testing other stuff.

-- hugh

 

[shawnmcginn]

Ajax validations now render the translated values! Thanks so much for fixing that piece.

The only issue still remaining is translated content in the CDD. I'm using a CONCAT label, where the translations are stored in a separate table matching on {lang} but it always brings back the english version. (see query below) I've upgraded my fabrik install and uploaded the git update as mentioned earlier but still no luck with this piece. Note my country dropdown works the same as the province/state cdd using a CONCAT label query, and translations work fine for that element.

Here's my CONCAT label subquery for the province/state cdd:

(SELECT regions_trans_labels.label FROM regions_trans_labels
WHERE CONCAT({thistable}.country, {thistable}.code) = CONCAT(regions_trans_labels.country, regions_trans_labels.code) AND regions_trans_labels.lang = '{lang}')

 

[cheesegrits]

OK, I think I thought about that ... {lang} will only contain the pre-configured J! language or the logged-on user's choice, the result of ...

        $lang    = JFactory::getLanguage()->getTag();

However, if you have a look in ./components/com_fabrik/helpers/parent.php, around line 921 you'll find this line commented out:

        //$multilang = FabrikWorker::getMultiLangURLCode(),

Uncomment that, then add this line around 932, right after we set {lang} ...

            '{multilang}' => $multilang,

... then use {multilang} in your query.

I didn't add that because the getMultiLangURLCode() is a fairly expensive call, and I wasn't 100% sure I needed it at that point, then forgot about it. If it works for you, I'll commit that change.

-- hugh

 

[cheesegrits]

Ooops, change that comma on the end of the line you uncomment to a ;

-- hugh

 

[shawnmcginn]

Yep saw that. Now when I first load the page it shows my 'please select(fr)' so I know it first loads the french values (even though it's empty but that may be something I need to tweak in the concat) but now when I change the country dropdown, the cdd is updated and reverts to english.

 

[cheesegrits]

*sigh*

I'll have to reconfigure my site for multiple languages again, which I can't do right now, as I'm working on some stuff it gets in the way of.

-- hugh

 

[shawnmcginn]

one question, what does {multilang} equate to? Does it come out as en_CA or en-CA?

 

[cheesegrits]

Whatever you set the language URL code to in the content languages, which is what has to be appended as &lang=xx on the query string.

-- hugh

 

[cheesegrits]

Hmmm, I may not be doing the right thing there. I need to wrap my head back round all this stuff, but I just can't reconfigure my site for a while, till I've finished a couple of tasks I'm working on.

-- hugh

 

[shawnmcginn]

Any chance you could have another look at this sometime this week? Everything else looks good so this is the final piece and I should be fully translated. (Except of course upload fields but I guess they are translated based on your browser configuration)
Thanks!
Shawn

 

[cheesegrits]

Are you sure {multilang} isn't giving you the selected language? I just tested, and it gives me the language code as defined in in the content language. So I have en-GB configured as en, and fr-CA as frca, and that's what I get in {multilang} ... en or frca.

-- hugh

 

[shawnmcginn]

Sorry, I got pulled off onto another project but am now back to take another look at this. What I've found is on the second call to globalReplacements in parent.php, multilang is actually set to en and lang is en_CA. Subsequent calls to this method and on the first call, those values are set to fr/fr_CA. I debugged this and found the language cookie is set to fr-CA and the http_referer has the lang=fr in the URL. Seeing as the cookie 'key' is encrypted or serialized, I'm really not sure how to pull the 'lang' cookie so for now my solution is to replace lang with fr_CA should I find lang=fr in the query string.

$multilang= FabrikWorker::getMultiLangURLCode();
$session= & JFactory::getSession();
$referer=$session->get('referrer',$_SERVER['HTTP_REFERER'], 'extref');
if(preg_match('/lang=fr/', $referer)){
$lang= 'fr_CA';
}

This fixes the issue with incorrect translations in the dropdown values. So the only remaining piece is now to get the 'please select' statement translated and I should be ok. Kind of a hokey workaround but where the ajax call is within the application I'm hoping the referer will never change.

Shawn