There are various settings in Facet API where users can submit custom strings. Currently there is no mechanism in place to translate the strings. In an effort to avoid tight coupling with the i18n module inside of the core Facet API module, there should be a generic translation function that allows a contrib to interact with the strings and translate them via their native mechanism. By separating this out, an isolated contrib can be maintained to decouple it's release schedule from core Facet API so it can innovate at it's own pace.

Comments

cpliakas’s picture

Adding the stable release blocker tag, as this is critical for i18n.

cpliakas’s picture

Status: Active » Needs review
StatusFileSize
new9.85 KB

The attached patch implements the strategy mentioned in the OP. This would allow the translator module to integrate with i18n and look something like the code below:

/**
 * Implements hook_facetapi_translate_string().
 */
function MODULE_facetapi_translate_string($name, $string, array $options) {
  return i18n_string($name, $string, $options);
}

The major benefit of this implementation is that is eliminates the need for logic surrounding the i18n module in core Facet API and allows a translator contrib to have different release cycles.

cpliakas’s picture

Status: Needs review » Needs work

Requires a hook_facetapi_translate_string() definition in facetapi.api.php.

cpliakas’s picture

StatusFileSize
new11.32 KB

Added the hook definition to facetapi.api.inc, made some other minor improvements.

cpliakas’s picture

Status: Needs work » Needs review

Marking as "needs review".

cpliakas’s picture

StatusFileSize
new11.36 KB

Comment improvements.

cpliakas’s picture

StatusFileSize
new11.33 KB

Ugh. Removed stray dsm().

cpliakas’s picture

Please excuse typos in comments.

Posted against wrong issue.

cpliakas’s picture

Status: Needs review » Fixed

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