Datatables 1.9 internationalization problem

hsanjuan

Hello, after upgrading from 1.8.2 to 1.9.1 I have noticed that an error pops up in what seems to be a problem fetching the datatables translation file. Im not sure to how it extents but to me it appears inside _fnInfoMacros saying it is trying to do a .replace on a null value. It is called from this context, so sZero is null.

[code]
var oLang = oSettings.oLanguage;
var sZero = oLang.sZeroRecords;
if ( oSettings.iDraw == 1 && oSettings.sAjaxSource !== null && !oSettings.oFeatures.bServerSide )
{
sZero = oLang.sLoadingRecords;
}
else if ( oLang.sEmptyTable && oSettings.fnRecordsTotal() === 0 )
{
sZero = oLang.sEmptyTable;
}
var nTd = document.createElement( 'td' );
nTd.setAttribute( 'valign', "top" );
nTd.colSpan = _fnVisbleColumns( oSettings );
nTd.className = oSettings.oClasses.sRowEmpty;
nTd.innerHTML = _fnInfoMacros( oSettings, sZero );
[/code]

The funny thing is that if I set a breakpoint before var sZero = oLang.sZeroRecords and move forward step by step then the value is set correctly. It seems oLang is not ready as soon as datatables try to use it. It works well in 1.8. Maybe it's a bug? Upgrade notes don't say anything about changes in internationalization. Im using Firefox 11. Thanks!

allan

This could well be a bug introduced in 1.9.1 ( :-( ) as I did do a few modifications in this area. I don't understand why sZeroRecords would be null though - i don't think that should ever be the case, Could you show me your initialisation and translation file?

Thanks,
Allan

hsanjuan

The init is made as:

[code]
dataTable_vMachines = $("#datatable_vmachines",main_tabs_context).dataTable({
"bJQueryUI": true,
"bSortClasses": false,
"sPaginationType": "full_numbers",
"bAutoWidth":false,
"aoColumnDefs": [
{ "bSortable": false, "aTargets": ["check"] },
{ "sWidth": "60px", "aTargets": [0,6,7] },
{ "sWidth": "35px", "aTargets": [1,11] },
{ "sWidth": "150px", "aTargets": [5,10] },
{ "sWidth": "100px", "aTargets": [2,3,9] }
],
"oLanguage": (datatable_lang != "") ?
{
sUrl: "locale/"+lang+"/"+datatable_lang
} : ""
});
[/code]

And the translation files are taken from http://datatables.net/plug-ins/i18n. It happens when using the normal English translation file. Also when leaving oLanguage to "".

Thanks,
H

bule

Hi all, I find the same problem with the 1.9.1 datatable ..
I'am updating the datable plugin im my web site from the 1.4 (quite old ;) ) to the 1.9.1 and this is the only problem I find...
also for me if I try the javascript with break point it works good---

Thanks a lot for help

allan

Can you give us a link to a test page showing hte problem please?

Allan

bule

Hi Allan,
you can try with this link. if I don't use the sUrl paremeter for language all work good

http://developer.itecsonline.net/ctwebinterface/controllo.php?pagina=datatable&user=fzoroaster&passwordcrypt=616706c4d6f7bdf68b30893f860cbb2b

Thanks a lot for your great plugin ..

allan

Could you try adding:

[code]
"sLoadingRecords": "something...",
"sEmptyTable": "something else..."
[/code]

to your language file and see if that helps please?

Allan

bule

Hi Allan,
just add what you ask to me but there is the same erros..as hsanjuan told if you try to put some breakpoints in the fnInfoMacros function it works good..it seems that there is some problem in the timing between the async call..

you can see the modification at the same link ..

bule

Hello Allan, have you seen the link I post ?
Is there a bug in the datatable internationalization or am I missing something ?

Thanks a lot

supernaut

Not sure if this is the same thing, but I found this works:

[code]
var $htmllang = $('html').attr('lang');
'oLanguage': ( $htmllang == 'de-DE') ? {
'sUrl': languages/de_DE.txt'
} : ( $htmllang == 'fr-FR') ? {
'sUrl': 'languages/fr_FR.txt'
} : ( $htmllang == 'en-US') ? {
'sUrl': ''
} : ''
[/code]

The var is not so important, you could call the language in other ways, it's just how i happen to be doing it elsewhere.

What seemed to be important here is that the default language (en-US) had to have its own statement, as well as the closing empty " : '' ". One or the other alone didn't work.