User hint and Empty field description not available for translation

If you're actually working on a translation, I'd love to hear about it.

Unfortunately, those two fields, user hint and the empty field prompt, are set by the administrator. Translations work on text strings that are in the module source itself. For example, you might see something in the code like:

  if (!is_numeric($w)) {
    form_set_error('mothermayi_weight', t('Weight must be numeric.'));
  }

In this case 'Weight must be numeric." will appear as the error message. Unless the current user has a different language setting for which there's a translation, in which case the translation of "Weight must be numeric." will appear. The person doing a translation can look at the code, find all of the things that need translation, and supply the appropriate translation for each.

Those two prompts, however, since they're supplied by the site administrator, can't be translated beforehand. You'd need a much more intelligent translation system for that.

Now I suppose it might be reasonable to ask for the ability to set different prompts and secret words based on he user's language. I thought about it, but didn't think it was worth the effort for several reasons.

1. I'm not aware that anyone has done translations for this module. (Feel free to prove me wrong.)
2. The site administrator is free to use whatever language s/he wants to fill in the prompts. There's no reason that a primarily French site couldn't have a French prompt.
3. Since this is only used for anonymous users, can there be a user language other than the site's default language? Maybe there can. I've never dealt with Drupal internationalization.

I guess I'd consider it if I could be convinced that it would be widely used.

BTW, there's at least a half a chance that I'm telling you things you already know. And at least another half a chance that you know far more about this than do I, and know that there's an easy way to deal with that. If true, please enlighten me.

Well, yes, I did know that those fields wouldn't be translatable, due to how translations normally work. But the Variables module looks interesting. I don't know, though, how it would work in practice.

If someone stepped forward who was actually interested in doing a translation, I'd be willing to work with them.

Hi, please review my patch.
I changed mothermayi_secret_hint format because I believe it made code simpler - no additional callbacks for hook_variable_info are required and few lines could be removed from _mothermayi_settings_form_submit.

Maybe adding all these variables is a bit of overkill, but it doesn't cost much. Just for the sake of translatability one could limit himself to secret_word, secret_hint and empty_description I guess.

fau -

I looked through these. What I see:

• A bunch of "used in one place" string constants turned into DEFINES. OK, that's a style issue. Personally, for this kind of thing (where a string is used in only one place) I find it makes it somewhat harder to follow the code. But I don't object.
• Two variables coalesced into one. It seemed gratuitous to me, but it looks like it simplifies some things. I need to think about it.
• hook_variable_info() is a new one on me. Seems like a good idea.
• A few whitespace changes.

So yes, these clean some things up. But here's my big question: Why attach this to this particular issue? Maybe I'm missing something, but I don't see how it addresses the original feature request. Unless I'm missing something, it doesn't let you use the standard translation system to translate the admin-entered user hint and empty field description. The translation system is only set up to translate fixed strings in the code, not user-entered data.

The only way I can think to do that would be to turn the prompt fields into arrays, keyed by language, so the admin could set up different prompts for users with different languages. (And I'm not sure how that would work with anonymous users, which is the whole point of this thing.)

And sorry, I consider tacking an unrelated change on to an old, closed issue, however valuable that change may be, to be bad form. This really ought to be a new issue.

This patch resolves the issue. quimic in #2 suggested integrating Variable module as a solution to original problem and this is what this patch does (by implementing hook_variable_info). The fact that there is no strict dependency may be misleading.

In order to test it enable "variable" and "i18n_variable" modules, and add an additional language(s) to your site. On page /admin/config/regional/i18n/variable under "User settings" mark your variables as translatable. Go to Mother May I configuration page and use a language selector at the top to configure it for each language separately.

Two variables coalesced into one. It seemed gratuitous to me, but it looks like it simplifies some things. I need to think about it.

There is an incosistency in drupal core when it comes to handling text_format type fields. FAPI expects two separate keys, '#default_value' and '#format', however system_settings_form returns an array with keys 'value' and 'format'. hook_variable_info expects these in array, having them in separate variables, as previously, would require writing two extra callbacks.

I don't like these defines neither, I added them to not duplicate strings in mothermayi_settings_form and mothermayi_variable_info. I also don't like the fact that this patch introduces so much API glue in such a small module. On second thought this "lite" version may be more appropriate.

Fau, thanks for the clarification. Sorry I've been ignoring this. I haven't had a lot of free time lately.

I'm far from a Drupal API expert, and internationalization is something I've never had to deal with in Drupal, so haven''t spent a lot of time thinking about it. I didn't realize that translation was the point of those new hooks. I'll try pulling in the patch and creating a dev version. Hopefully someone who wants translatability will try it out.

Question: Since this uses Variables, should that be added as a dependency? Or is that something that only someone who needed translatability would need to install?

Or is that something that only someone who needed translatability would need to install?

Precisely. If variable module isn't installed, mothermayi_variable_info hook doesn't get registered and everything works as previously.
Apart from new mothermayi_secret_hint variable format and the fact that Emptyfield description uses filter_xss_admin now.

It's been a long time, and my Drupal memory is pretty stale, but now that I've finally gotten a new development environment set up, I'm going to look at applying this patch.

Fix from @fau in release 7.x-1.6.