Would be great to have it in 3.10 because translation is broken. (No string change involved.)

I don't think this is the correct approach. If you look at members/readingrec.tt you can see that the table footer *is* translated. The difference is that the initialization of the table sorter on that page includes a directive to extend according to some defaults:

    $("#table_readingrec").dataTable($.extend(true, {}, dataTablesDefaults, {
        "sPaginationType": "four_button",
    }));

dataTablesDefaults loads the configuration in datatables.js which loads the variables defined in datatables-strings.inc. And datatables-strings.inc exists expressly to be picked up for translation, so duplicating its contents shouldn't be necessary.

That said, simply adding $.extend() to the datatables configuration in quotes.tt doesn't work for me and I'm not sure why.

In this case, the architecture the code is fundamentally wrong and should be re-written?

Who would have time to do it? 

And in the meantime we have ugly non-translated text in localized versions I wanted to get rid of.

I tried for several hours but I can't make it work with the approach Owen suggested. It seems that the table definition is to complex to be merged with dataTablesDefaults.

If I extend it with:
    oTable = $("#table_readingrec").dataTable($.extend(true, {}, dataTablesDefaults, {
...
    }));

...the table simply does not render. I suppose that it breaks the callback definitions. 

My patch would be a workaround to avoid untranslated strings and does not break anything, but maybe somebody else (the original author of this feature?) is able to put the code in a way that it does not fail QA.

(In reply to comment #5)
> I tried for several hours but I can't make it work with the approach Owen
> suggested. It seems that the table definition is to complex to be merged
> with dataTablesDefaults.

This is true. dataTablesDefaults seemed to impose some restrictions which I was unable to workaround. And I seem to recall not being able to modify the extension to render it usable for my purposes.

> 
> My patch would be a workaround to avoid untranslated strings and does not
> break anything, but maybe somebody else (the original author of this
> feature?) is able to put the code in a way that it does not fail QA.

I think this is a good workaround. It uses the same basic approach as the extension and one which is (iirc) recommended in the DT documentation. It would be nice to explore the idea of separating the strings from dataTablesDefaults, allowing perhaps a more benign extension of DT to just include strings.

Changing the status back to "Needs Signoff." I don't have multiple translations installed atm, so if someone who does could verify and sign-off, that would be good.

Qa comment:
 * small patch, no side effect
 * make strings translatables
passed QA

Created attachment 13550 [details] [review]
Bug 9017 - Quote of the day: Table footer not translated

The strings for the table footer of the QOD feature are translated in /datatables-strings.inc, but they did not show up in staff client due to missing code in quotes.tt -> $(document).ready(function(), part "oLanguage"
Code added as appropriate.
See: http://datatables.net/usage/i18n

Additionally, quotes.tt had a stray </script> tag after [% INCLUDE 'datatables-strings.inc' %]

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>

This patch has been pushed to master.

Patch pushed to branch 3.10.x

Released in 3.10.0