Static link text cannot be translated

Patched per wolfi's suggestion.

(added a t() to
$title = $item['title'];

)

Link titles are user data, most of the time. Static link titles, though, are part of the interface (most of the time), you should only translate this kind of titles. Otherwise, user-input titles can get accidentally translated.

I guess you should check for the kind of title, then get t() applied on it.

Actually, as barraponto pointed out, I did not t() the right title.
Here is a new patch, t() it even more globally (this will include user defined title AND static titles), which I think is what t() is for.
Please, only review this if you ever had to deal daily with t() (as in foreign language site builder).

Where is that link.inc file supposed to be? Am I missing something here?

@boazr: t() is meant for interface strings, not for user content. you should look in the api for t() http://api.drupal.org/api/drupal/includes--common.inc/function/t/6 where it says

However tempting it is, custom data from user input or other non-code sources should not be passed through t(). Doing so leads to the following problems and errors:

• The t() system doesn't support updates to existing strings. When user data is updated, the next time it's passed through t() a new record is created instead of an update. The database bloats over time and any existing translations are orphaned with each update.
• The t() system assumes any data it receives is in English. User data may be in another language, producing translation errors.
• The "Built-in interface" text group in the locale system is used to produce translations for storage in .po files. When non-code strings are passed through t(), they are added to this text group, which is rendered inaccurate since it is a mix of actual interface strings and various user input strings of uncertain origin.

Another problem is that the static link title is not recognized as translatable data by the i18n_strings module, so it cannot be translated into a foreign language at all. As noted above t() isn't the right thing to use here...

I'll see if I can fix this, and if so, I'll put in a patch.

Ugh. This will not be easy to fix actually, at least for i18n purposes. The i18n_fields module has hard-wired that when you are translating a field (i.e., the field settings), it only lets you translate the label, description, and the allowed values (for select/radio/checkboxes types of fields). There is no way to tell i18n_fields that the static link text also needs a translation, unfortunately. So fixing this for internationalization would also require fixing i18n_fields.

I'm not sure whether String Overrides uses the same mechanism or not as i18n, but it looks bleak for i18n at least.

@jhodgon I believe Static Titles are not content to be internationalized, but part of the UI. They are defined once for the field — every instance of the field. So I guess it makes sense to pass it through t() and localize it through admin/build/translate.

You cannot pass *any* user-defined text through t(). That is just not the way to translate user-defined text. Period. See #5 above.

#3 worked perfectly fine. it exactly was the solution i've been looking for (translatable user input in field titles).
thank you!

I was wondering: can't we wrap the static title in t() when we're loading it from a feature? Or will it find its way into the database anyway?

It will. Here's another way to think about it: If your string isn't in code, it can't be put in t(). So anything entered from the UI, is not t()-able. The solutions posted above are therefore not helpful in the long term.

I think we should get this figured out in D7 first, and then backport if necessary.

I created a patch that uses i18n_string when available to translate the static titles. For now, it's only translated on a field instance level, but it shouldn't be too difficult to expand the code.

Changing the issue category to feature request, because this isn't really a bug.

@ all: Thanks for the effort, but maybe the title is not translatable because it is strongly connected to the destination it points to and therefore its own language and not the language of the site? Not sure. Maybe it is not meant to be a description in the language of the site. Barrapontos obligation is a good hint at this point too.

To be honest, I even don't like the whole attempt of a title field pasted sticky with the link field, but I accept that it is useful for some approaches regarding the content the link points to. (f.e. website titles) The way I do it on our projects is, that I provide another additional text field near to the link field and its title, which is translatable and can be used with tokens to create a static describable title attempt. Field collection is an awesome module for such purposes. This way we would prevent cluttering the link field and can change the way how to do it on any other content types much better then sticking on link field. Not sure but I would like to vote for link field module providing link field :-)

Anything apart from the url field itself is already quite expanding the link fields role in whole game and already breaks enough rules of D.R.Y. and modular systems like Drupal, where all flexibility is given already from scratch to solve such tasks in a much better and more flexible way than implementing it "hard" into the link field itself. Could you please try around a little bit more with how to solve this with tokens, views, display suite and field collection (just to count some of many) and then we should think twice before reopening this issue.

Thanks for understanding

Digidog: With all due respect... I realize that it is difficult to do, but having user-entered data in a module, especially something like this (a static title that is output with every link and is visible to the site visitor), that is not translatable to other languages, is a bug. See:
http://drupal.org/node/304002

I'll just put this out there once... as you are the maintainer of the module, you can close this issue up again, but in my opinion it is not the right answer for the maintainer of a rather prominent module to say "Sorry, this module is not fully internationalized, and only single-language sites can use this feature effectively".

jhodgdon: With all due respect ... Are you sure that you meant me?

On which point I sad:

difficult to do

?
On which point I sad:

"Sorry, this module is not fully internationalized, and only single-language sites can use this feature effectively"

?

And on which point I wanted to discuss if this is a bug or a feature request? Or when do I claimed that I have the only "right" answer or that I am the only maintainer of this module? I am really a little bit curious that, since I don't remember that I sad that anywhere and also a little bit about the way you discuss here. Also before this already. ("period"?) Provocating other users is not the way how a community discussion will gain any success.

And it doesn't matter if you say that I am a maintainer of a "prominent" module. Which is wrong, if it is written without any further additional explanation on this, since the most hard work on this module was made by earlier maintainers like jcfiala, dropcube, quicksketch and the community. Look, I am not a Drupal consultant nor do I provide Drupal services or anything similar what could take out any useful promotion on this. All I do is helping and spendning my sleepless nights with it. I don't see anything here in the room I sit, nor when I speak to somebody in the community which marks me as a module maintainer of a "prominent" module or such and, by the way, the module is mainly driven by the community and the author not by me. All I sad is, that it is not a D.R.Y. solution to expand the field titles role here in a framework, building features sticking around it and reinventing the wheel without looking left and right.

If you think this should be in, ok, fine. Its a community thing. Convince the rest of us here, why you think the rules of a modular framework and D.R.Y. application development should be broken to paste a sticky title field on a link field and please also provide patches or any other useful output on this. This is a free place, and nobody including me owns this module. But please don't insult me with things I didn't say nor please advice me what the "right" way is to do here, since I work hard to get done with link field issues and are maybe a little bit touchy on this "sound". ( I hope you don't get me wrong on this )

I agree that this is a bug, and support the idea that titles should be string-translatable.

colan, good to hear that you support that idea. But briefly, I don't have a problem calling sth. a bug. Can we please stop that missleading subdiscussion, because I never sad at any point, that this isn't a bug. Even if I rather more agree with barraponto and zilverdistel here. (Thanks for your efforts btw)

All I try to say is, that I am not sure why we actually support a text field sticking on the link field in general, if we have the only CMS out there on the market which supports building forms with different fields out of the box? Sorry, but I don't get it.

Please provide an idea / solution for that. I would looove to get input here since I respect your user wishes. But last time I heard that somebody wants to support an idea, it was in IRC some days ago and after I followed the wish from there, I was talking to myself on the regarding issue then, wrote a patch, tested the patch and reviewed the patch and have implemented the feature allone with myself -> #1441702: Rel attribute should have an option to get automaticly turned on/off if link is internal/external

So being sad, I will press the unfollow button now until there is sth. meaningful to review here. Sorry and thanks for understanding.

I'm afraid I don't really understand the resistance to this. Perhaps someone can try explaining it in a different way? It sounds like there's another conceptual idea here that I'm missing.

No resistance at all, colan. - If - there is an agreemant on a title field in general, THEN it is maybe a bug, except the other oblications made above for good reasons. But as I sad: The -if- is the word I am after.

Please provide an idea/solution for that

Sorry if my english is missleading sometimes. I am not a native speaker.

Hey folks, lets cool down a little. Digidog puts in a lot of time on this module, so give him a little time to work through the options. Digidog didn't remove the 'bug report' category from the ticket, zilverdistel did.

I like the idea of having the static link title being translatable, and of getting the whole field to be translatable, but the fact remains that t() is not supposed to translate anything that comes from a user - it's supposed to work with the module text. I'm not even sure that it'll work all that well for translating.

That being said, what do the people who want this to be translatable think of the patch that was provided by zilverdistel in #13? I'm not familiar with the i18n module and how it's supposed to work - is this a good start on solving the problem?

Digidog: I sincerely apologize for my comment above. I was trying to point out best module development practices, not offend you. Of course we all appreciate the time that many module developers, including you, put into the modules they maintain or co-maintain.

To clarify what this issue is about... This is actually about the link text, not title attributes in links. There is an option when you create a Link field that says something like "Use this static link text for all links, and just let the user enter the URL for the link". For example, you can use this to make something like a "Read full article" link by just having your content editors enter the link URL in the Link field. This admin-entered static link text ("Read full article" in this case) is what should be translatable. I've changed the issue title accordingly.

Regarding the patch in #13, I haven't tested it and haven't looked at it in detail, but yes, using the i18n_strings module is the right approach, not t() [as was pointed out in comments above]. To test it, you would want to:
a) Apply the patch on a site set up with multiple languages.
b) Create a Link field with a static link text (as described in the previous paragraph).
c) Verify that this static link text is translatable in the Internationalization translation interface.
d) Enter some content with a URL for the link field.
e) Verify that the correct link text shows up on your content item when viewing the content in different languages.

@jhodgdon: Thanks for coming back on this, I really cherish your words to smooth ruffled feelings and I know that your schedule is also very tight. As mine. But please don't get it the wrong way that I have to get back to some points here offtopic, to prevent talking at cross purposes:

Since I know module development practices and I pretty much know that it is about the title text here :), there is no clarification needed on this. Maybe the tangle is caused by my not native english and the more possible missunderstanding caused by this "between the lines" thingy when reading/writing in forums. But I appreciate your efforts on elucidation and want also to say sorry if there was anything sounding harsh on what I answered.

But in fact, what I was after here the whole time was: before we move something "in" regarding this title text field and before 3 others start to waste time for patches on this, I see the need to discuss the title text field as a whole, conceptually. That's what my worries were all about.

I mean the title text field sticking together with link field in its entirety. The whole title text field is a reinvented wheel of a default text field with some additional modifikations, but which are all already available in the system, like: default value, implementing tokens, translation, and many more, and which can be combined with anything else you want (link fields, tokens a.s.o.) and which are already translable by default and have more chance to stay translable as such when the wind of change blows thru' the Drupal core. And what finally leads me to remind you all about the common practice in Drupal, combining things to bigger things to make it an individual tool to your needs is what this is all about here and what is better than writing a module which reinvents all this and pastes it together. If it is a content type, a group of fields (once again: field_collection!) or the whole idea of how entities will work (hopefully soon), it all should lead to the conclusion, that this discussed title text field here is like if we would start to code a form api to save the link on the bottom of the link input form again. I talk about the UI level. Not the hook level.

The way how it is now with the link field module and its title text field, how they stick together now in the UI, how they are only vertically extensible in the UI this way (instead of horizonally, like it should) and how it becomes more absurd now after anything more "patched" on this, is a pretty joomlaish-second-text-field-sticking-on-link-field kind of thingy for me, while we have a CCK driven system running under it on the other side, which is basically made to combine its building blocks to an indivdual application and to many more but really extensible, horizonally.

The title and alt attribute in the link markup is a completely different discussion, since the title and alt attributes are W3C conform HTML markup standart and wouldn't never make sense as a autonom thing from link field module. So there were never a missunderstanding from anyone here, I think (I hope).

So again: What I wanted to point out the whole time is, that I am not really convinced about the need of this title text field (but accepted its existence until this issue aroses), since we are talking about a framework-like WebCMS, which supports building blocks and combine them to application groups (like entites, input forms, views, etc, etc.) But I also obligated that if nobody wants to benefit from the flexibility I want to offer with my thoughts, I am fine with this, since it isn't my decision. Sorry, I tried my best with my english. The time I used to live in US is about 10 years ago :) Do you get what I am after?

I also hope it was clear enough that I am absolutely able to take criticism or advice, if I think it is at the right point. Kindness of old age (almost 40) makes it possible. :) But here seems to be still some missunderstanding or quick overreading of certain things I wanted to see clarified.

Kind regards and greetings from Berlin, Germany

Ah... so, I think what you're saying, Digidog, is that the title part of the link field should be based on / built on the standard text field, which already has integration with i18n and other functionaly, and that the link field should just be adding those things which are necessary for links, such as the url and the various options?

I'm certainly not opposed to someone looking into that, although we may want to think of that as a possible 7.x-2.x branch, because it really sounds like tearing open the existing module and rebuilding it, although I could be wrong as I'm not as familiar with fields in D7 as I could be.

It may also want to be it's own issue / thread.

Ah... so, I think what you're saying, Digidog, is that the title part of the link field should be based on / built on the standard text field, which already has integration with i18n and other functionaly, and that the link field should just be adding those things which are necessary for links, such as the url and the various options?

Basically, yes. I think you are the first who understands what my thoughts were about here (no offence). And well yes, many questions are still around this. Many things you added for consideration are true and already in my mind. New branch, etc. But first, we have to sort out if it makes sense to re-engineer a field type module for this. I rather see these modules as helper modules for the lazy. Field type modules and node type modules are certainly impasses in a modern Drupal world. You can gain mostly everything you want including full translation support and many more with only 3 or 4 input type fields provided by core today in combination with other modules, which are common and installed on most of the advanced Drupal installations already out there, to create any extended link or other type of field form, expandable and combinable in any thinkable way these days.

I wrote long articles about the UI abstraction layer in Drupal and why these too specified field type modules are not flexible enough for many modern use cases in comparison to building block solutions like the field_collection / field_validation combination, to mention one example. But I never published it because it feels like a never ending discussion about different Drupal philosophies, I don't have the time to. I half made a screencast on how to use 2 simple text fields only, to create a complex and full featured link field power application form, which is hard to beat from the link field modules side. Because the link field module can only expand "vertically" but not "horizonally" (pluggable?). And the feature requests regarding vaildation ,f.e., will never end, because every usecase will bring up missing features which have to be build on top. UI abstraction layer is one the biggest advantages of Drupal, but ironically the most overseen. ok, but all this is finally useless here to discuss and rather customer support, or not meaningful for the development of the link field module or this issue here, I guess.

jcfiala, if we want to avoid more feature overload, because the link field module edit form is already deeply cluttered, then we need a more strict feature request policy to prevent these endless work on an impasse. The link fields purpose ends on a certain point. That's where my question comes from, if the extra title field isn't a potentual seduction, which makes it easy to define the meaning of the link field module and its limitations down and starts to make users think, oh but I miss this and that on it, lets make a feature request.

However, I didn't wanted to offend anybody and tried to paint a bigger picture here. In fact, we have the title field now and maybe we should support translatable title for God's sake to let this story end here in a good way.

But after that we should really stop the feature request vapor which creates tons of double code which is already provided by core and should refer to alternative solutions from there.

@Digidog: I believe the static text field is useful and adds lots of value to the module. jhodgdon showed a possible use case, there are plenty indeed, like social networks. Of course it can be accomplished from the theme layer using t() with a static string, but the static text allows the site builder to do it with zero code.

What I'm not sure right now is whether Field Translation is enough to handle this. I'm low on time to test this, but translation-savvy developers or site builders might know the answer at a glance.

Sorry, I did not read the whole story I was pointed here to help move this forward. Some rules of thumb:

1. If this value solely comes from source code and is NOT user editable, then using t() is good.
2. As long as this is user editable configuration in any form, i18n_string is indeed the best approach available for now in D7. (The configuration might change anytime, there are security concerns, etc, so t() is a no-go. See the first 9 points at http://hojtsy.hu/blog/2011-may-19/drupals-multilingual-problem-why-t-wro... to understand why).
3. If the value is stored with each entity/field, looking at entity translation would be best. That lets you store data individually related to entities and languages.

I think this issue is concerned with field configuration, that is (2), so the i18n_string patch looks like might be the best direction.

So, @jhodgdon, should we mark this as postponed or move it to i18n to fix the limitations on i18n_strings?

RE #28 - What are the limitations on i18n_strings you are referring to? I don't think there is any problem with using i18n_strings to fix this issue, assuming that the feature of being able to provide static link text is going to be retained (which I think is very useful, as discussed above). Many modules are using i18n_strings. It is the standard and it works fine.

@jhodgdon i meant the limitations you have described in #7:

Ugh. This will not be easy to fix actually, at least for i18n purposes. The i18n_fields module has hard-wired that when you are translating a field (i.e., the field settings), it only lets you translate the label, description, and the allowed values (for select/radio/checkboxes types of fields). There is no way to tell i18n_fields that the static link text also needs a translation, unfortunately. So fixing this for internationalization would also require fixing i18n_fields.

I'm not sure whether String Overrides uses the same mechanism or not as i18n, but it looks bleak for i18n at least.

Whoops, forgot about that. :)

Well, link module could either use the same technique then that i18n does to translate the field properties (you don't need to have support for it in i18n_field), or better, make i18n_field pluggable with more field config properties and just implement the hook in link module. Better for all other field types who need custom properties translated.

Patch #3 did the job for me.

It wasnt actually the exact area, but heres my patch.

@webadpro: t() is unfortunately not the solution for user input translation, see http://hojtsy.hu/blog/2011-may-19/drupals-multilingual-problem-why-t-wro... for quite a few good reasons.

Although its not in the user input its what you write in the field instance settings.

Your are not alter the title if you let the user choose their own title in an entity form.

I think if the admin configure his fields, he is aware of translation.

@webadpro: well, who fills in the field settings? Users! It is not the kind of user who actually creates your nodes, but they are users anyway. Basically we have this distinction of "values that can be modified on a user interface" vs. "values that are baked into source code", and t() applies the second group.

- Lost in translation -
I commented something stupid here, then I remembered that the link title can be "exposed" to end-users, so t() is not an option.

I'm trying to find out if somebody tested the patch I provided in #13, and how it could be improved. Impossible to read the comments in this issue ... Can somebody point out if my patch works or not?

@zilverdistel:
I tested you patch from comment #3. This works great. I am now able to translate my static link text.
However, there is still one error shown, when translating the field:

Notice: Undefined index: widget in link_i18n_string_list_field_alter() (line 243 of /etc/drupal7/all/modules/link/link.module).

Although i know that this line was not changed applying the patch (which i did by hand, btw), the error was not thrown before and i guess is related to the patch.
After patching the file line 243 now is:
"if ($type = 'field_instance' && $object && $object['widget']['type'] == 'link$" in the mentioned function "link_i18n_string_list_field_alter"

Hope this helps a bit.
But since i am able to translate the static link text, all thats left to say is: "good work" :)

@zilverdistel: I have tried Patch #13 and it works great.

Only issue I was having, was finding the text in the translate interface because of the following line:

if (function_exists('i18n_string_update') && $prior_instance['settings']['title_value'] != $instance['settings']['title_value']) {

Since most of us have already a text in the field, i needed to modify my text then rewrite it in order to detect the change and apply the translation. Although, if this would be added in the module itself, then there wouldn't be any issue with this code.

Isn't there any good solution for this? I found the option "Label, as link with label as title" which should work since the label is translated and that is static and all but no, it just displays the value in original language.

@mErilainen it's not static, since it is defined by the site builder (a user).

For me #13 is working, and seems to be the correct way to translate.
Isn't that going into a code? I didn't found it in the current dev code...

I confirm that the patch in #13 works great and applies cleanly.

On a side note I needed to update the static link title before being able to translate it. At first I tried to clear caches, refresh the strings via admin/config/regional/translate/i18n_string and refreshed pages where the static title is displayed.

So maybe there is something to be done in an update function to have the string translation working directly for already defined fields. But that may be added in a followup since the patch works great and it seems to be the best way to do it. Thanks @zilverdistel !

@idflood, as stated on my post:

Since most of us have already a text in the field, i needed to modify my text then rewrite it in order to detect the change and apply the translation. Although, if this would be added in the module itself, then there wouldn't be any issue with this code.

@nathan6137 As long as the patch is not in, your best bet is a field template. You can set the title manually in there and wrap it in a t() function. This won't be broken by a minor update.

Look, if folks have tried the patch in #13, and it works great, then you set it to "reviewed & tested by the community".

Good news, everybody!

Okay, I've got the changes from comment #13 included into the project, and it should be part of the 7.x-1.x-dev version tomorrow morning. I'd really like it if someone could take a few moments and test it for this - I'm not familiar with i18n and how it works, so I'm not sure how to test this. (Alternately, if someone can point me to documentation on how to test this myself, I'm happy enough to do that as well.

I'd like to find out if this works soon, as I'm planning on releasing the 7.x-1.1 version this weekend.

Thanks!

Still it shows an error:
Notice: Undefined index: title_value in link_field_update_instance() (line: 1305 /*******/sites/all/modules/link/link.module).

Okay, if someone's getting an error, I'm moving this to active again.

Was this a field with a static title, Prague Man?

Again, I have no experience with i18n or how to test it, so I really need help with this one.

I am also receiving the Notice: Undefined index: title_value in link_field_update_instance() (line 1305 of [site]/sites/all/modules/link/link.module) error on a i18n site since upgrading yesterday.

In case it's useful info: the error occurs upon saving the 'Manage Fields' page, and my field actually has no title whatsoever (i.e. Link Title is set to 'No Title').

Since this issue is otherwise irrelevant to me, I probably can't help much with figuring it out, but I'll be happy to try any patches :)

In this other node I have attached the patch to fix it.

#1914286: 'title_value' in 'link_field_update_instance' undefined

#33 worked for me!
thanks!

I confirm this works fine in 7.x-1.2. Of course you need to enable i18n_field.

This being said, I disagree this being a duplicate. It might be "fixed as a side effect of another issue", but this is not the same as a "duplicate". That other issue does not even mention string translation. (I did a find-in-page for "translation").

"Duplicate" implies that this issue is redundant, which it is not.

I am updating the issue summary. Please correct if the summary is wrong.

I'm using a link field with the following option in a View: Label, as link with label as title, and eventhough this field translated (with the i18n_field module), it won't show the translated label in the View.

I applied the patch mentionned in #33, cleared cache, but with no luck. I tried both 7.x-1.3 and 7.x-1.x-dev (on a D7.38 installation) to no avail.

I tried #13 on a fresh 7.x-1.x-dev version which causes a WSOD. So I thought to bring this back to the attention. Feel free to mark as closed again if deemed appropriate.

I had the same problem with 7.x-1.3, here's a patch which solved it.

I used i18n_field as per description and everything went fine. From my point of view this should be closed.

Patch in comment #63 with 7.x-1.x-dev solves the problem.

fixed path in patch file

I'm confused: Several comments state that no patches are needed if the steps in the summary are applied. And still the patch in #66 got committed without any additional review?