Hi there,

I've been working with webform_localization on a project that has numerous webforms in one website. A lot of those webforms have common elements (such as grid options, e.g.: 'agree', 'disagree', ...) that I need to translate time after time because i18n_string saves them separately for each webform.

In #1 will be a patch that needs a good review which basically does one thing and one thing only: Run every public facing component string through t() with the context 'webform component'. This is only done on the user facing side, i.e. all _webform_render_component() implementations.

The advantage here is that, for simple webform implementations you do not need to go through all the hassle of webform_localization + i18n_string. Instead, you can translate your components as if they were part of the interface (which they arguably are).

Please review and commit this if this seems like a legit addition to webform to you. I've tested it locally and it works, but it could definitely do with an extra review.

Regards,
Kristiaan Van den Eynde

CommentFileSizeAuthor
#4 webform-localize-components-1968544-4.patch22.22 KBkristiaanvandeneynde
#2 webform-localize-components-1968544-2.patch22.22 KBkristiaanvandeneynde
#1 webform-localize-components-1968544-1.patch18 KBkristiaanvandeneynde

Comments

kristiaanvandeneynde’s picture

kristiaanvandeneynde
Primary language Dutch
Location Antwerp, Belgium
commented
Status: Active » Needs review
StatusFileSize
new webform-localize-components-1968544-1.patch18 KB

Never mind this patch, it was made vs the master branch.

kristiaanvandeneynde’s picture

kristiaanvandeneynde
Primary language Dutch
Location Antwerp, Belgium
commented
StatusFileSize
new webform-localize-components-1968544-2.patch22.22 KB

As promised, the patch.
Git aware and everything, for your convenience.

Please review it thoroughly, I don't know if we should remove the #translatable key on every component to avoid conflicts.

kristiaanvandeneynde’s picture

kristiaanvandeneynde
Primary language Dutch
Location Antwerp, Belgium
commented

The patch also seems to apply cleanly to 7.x-3.x so no backport needed there?

kristiaanvandeneynde’s picture

kristiaanvandeneynde
Primary language Dutch
Location Antwerp, Belgium
commented
StatusFileSize
new webform-localize-components-1968544-4.patch22.22 KB

I'm sorry about all the patches, the default branch for Webform is still 'master' and that has caused a lot of problems :(

Anyways, here's one that shouldn't throw any php errors.

kristiaanvandeneynde’s picture

kristiaanvandeneynde
Primary language Dutch
Location Antwerp, Belgium
commented

After looking at #245424: Make Webform multilingual (i18n) aware through contributed modules, I think we shouldn't remove the #translatable tags seeing as they are what webform_localization runs on. This patch may even break webform_localization's implementation altogether.

However, there should be some way to keep component translation centralized, instead of having a separate translation set for every single webform...

quicksketch’s picture

quicksketch
he/him
commented
Status: Needs review » Closed (won't fix)

Running user-entered strings through t() is widely regarded as incorrect use of the translation system in Drupal. Especially considering Webforms are nodes, technically that groups them in with "content". Any number of Webforms can be created by site editors and content creators.

From the documentation on t():

You should never use t() to translate variables, such as calling t($text);, unless the text that the variable holds has been passed through t() elsewhere (e.g., $text is one of several translated literal strings in an array).

The reason for this is that t() has no cleanup routines. Once you've translated a string, it stays in your site forever. If users are creating and editing questions regularly, you're going to end up with an endless list of translated strings that never get cleaned up after they're no longer in use. When the translation is bound together with the content, when the node is deleted the translation is also deleted.

So in short, I don't think I can accept this patch. If you use a module like webform_localization, you might be able to save yourself some trouble because when you clone a Webform node (say using the Node Clone module), then all the translated strings are also cloned into the new node. That might save you the biggest pain. I totally see where you're coming from that t() is a quick and easy way to get things translated, but unfortunately it's not a solution for all situations.

kristiaanvandeneynde’s picture

kristiaanvandeneynde
Primary language Dutch
Location Antwerp, Belgium
commented

Thanks for taking a look at this quicksketch.
I know t() isn't perfect for the situation but I just couldn't find any module to suit my needs.

The problem with Webform Localization and Node Clone is that once you update the translatable strings, all clones 'lose' their translations. This happens because the cloned webforms reference the original webform's translation only until a modification is made. After you update the strings, they each point to their own translation set instead of the original one, leading to two problems:

  1. The clones lose all of their translated strings
  2. Instead, every clone gets the same set of translatable strings

This leads to the ridiculous case where you get a boatload of identical translatable strings. For instance: If you have 50 clones and refresh the strings, you'll have to translate a simple answer like 'completely agree' to your language 49 times over. And that's just for one string...