Closed (won't fix)
Project:
Facet API
Version:
7.x-1.x-dev
Component:
Custom Search Blocks
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
28 Dec 2011 at 08:58 UTC
Updated:
8 Jan 2012 at 14:52 UTC
Jump to comment: Most recent file
Comments
Comment #1
netdreamer commentedPatch provided
Comment #2
netdreamer commentedComment #3
nick_vhDoes the replacement still work?
If so, then this is good to go :-)
Comment #4
netdreamer commentedYes, replacement still works and it doesn't seem to suffer of any caching issue.
Obviously, "[facetapi_results:result-count]" must remain in the translated string...
Comment #5
cpliakas commentedHi netdream.
Thanks for the contribution, but I am respectfully marking this a "wont fix" for a couple of reasons. One is that it is against best practices to use t() in exported configurations because it only works when the default configurations are being read from code. As soon as the configuration is overridden and saved to the database, t() won't be called. In addition, it will store the translated string in whatever the default language is for the user saving the settings, which is not good. A second reason is that user generated strings should not use t() for translations. Instead, modules should integrate with the i18n project to accomplish this. I added a pluggable translation system at #1376786: Implement a generic string translation function that will allow contrib modules to integrate with translation modules that will allow a contrib module to provide the bridge between Facet API and i18n, which I should contribute to D.O. within the next couple of days.
Thanks,
Chris
Comment #6
cpliakas commentedThe Facet API Translation module has been committed to D.O. and supports translation of this string among others.