Don't mark field->options['alter']['target'] as translatable

That list is generated when exporting a view; the actual entry in all translatable sections is listed there so that when a view is embedded into a module, the strings can be easily translated with the basic tools. The system doesn't do any checking of the strings to make sure they're valid and actually translatable, and what is actually in the field is dependent upon usage.

For example, you have a string that is just a token replacement for another field, but it could Just as easily be "click on [url]" which you *would* want translated and there is no way I can think of for a system to automate excluding only the right ones.

I'm not sure there's much point to manually editing them out, as they will only re-appear if the view is ever exported again.

According to http://www.w3.org/TR/html4/present/frames.html#adef-target it definitive makes sense to not translate the value of targets.

A good idea may be to add a whitelist/blacklist, what fields are allowed or not - to have translatable strings.

Well in fact you have to define the options which are available. On these definition you can set a flag whether an entry is translatable or not. See views/handlers/views_handler_field.inc::option_definition. Feel free to provide a patch to improve this.

As "." is not there by default, it's probably caused by some of your configuration. As always in the views issue queue
it helps a ton when you provide an export of your view. For example you can look at it to understand what you did.

Each individual field has a flag as to whether or not it's translatable. If you have an issue with a particular field being translatable or not, then file that issue. That is not what this issue appeared to be about. Please don't lecture me for closing this issue and then saying it's a different issue than you presented.

The issue you presented is that there are strings you didn't expect in the list of t(). This is, as I said, by design.

It is also not clear to me that 100% under no circumstances should the 'target' not be set translatable. It's entirely possible, but that would be its own issue where that field must be considered for as many possible use cases. If there is some use case where it needs to be translated then it should remain translatable.

If you have a numeric field you may, in fact, have a dot in your view because that would be the decimal which is a setting and is set translatable.

    $options['set_precision'] = array('default' => FALSE);
    $options['precision'] = array('default' => 0);
    $options['decimal'] = array('default' => '.', 'translatable' => TRUE);
    $options['separator'] = array('default' => ',', 'translatable' => TRUE);
    $options['format_plural'] = array('default' => FALSE);
    $options['format_plural_singular'] = array('default' => '1');
    $options['format_plural_plural'] = array('default' => '@count');
    $options['prefix'] = array('default' => '', 'translatable' => TRUE);
    $options['suffix'] = array('default' => '', 'translatable' => TRUE);

While it's certainly true that we do a kind of crappy job of localizing numbers with this setup, that also would be a different issue from what you presented.

A separate issue to address the translatability of 'target' is in order, given dereine's research.

Sounds like a doable task

I'm adding a patch to keep the "target" attribute from being listed as translatable.

Thank you, your code looks perfect, so committed and pushed.

Let's also get this into Drupal 8:
In general translation will probably be handled by some magic other system, but at least for proper documentation of which should be translatable we should update it there as well.

Committed/pushed to 8.x, thanks!