Remove all instances of <none>, <Hidden> and <br/> from translatable strings because they lead to import errors

Is 'None' really so special that it needs brackets at all? Or is it mostly a little hack to get it to show on top when alpha-sorting?

I think the punctuation around (none) is intended to denote that none is not actually just a string value like the other options. I could come up with a use case where I wanted to have a field with the literal value 'None' among the options, but also wanted the field to be optional.

However, elsewhere, we use - None - . Let's use that instead of parens for consistency.

And, of course, this needs to be rerolled.

Tagging as novice to switch over to hyphens around none (use whatever pattern you find elsewhere in core for that) and to reroll the patch on account of #22336: Move all core Drupal files under a /core folder to improve usability and upgrades.

Per #3 updated to use - None - and #22336: Move all core Drupal files under a /core folder to improve usability and upgrades

I thought about it for awhile and I can't think of a sane way to test this. The patch is clean, improves the consistency of our UI text, and helps resolve a localization issue.

While I can think of some ways to test this , this another case where the effort to test simply doesn't worth it.

It's possible/practicable to test all core strings against whatever validation a translation string needs to pass?

As far as I know, we don't have the architecture to do so currently. That's what I meant by "sane" way to test it. :) However, it seems like something we should maybe have.

There's some issue with localization and simpletest and/or the testbots, but I don't know exactly what it is.

Maybe we should open a followup issue?

I found another example of this: the taxonomy module has <root> as the option to set a term as the top-level parent. I assume this would have the same issue? Should we change all instances of that to - Root -?

Setting at NR to follow up on that and on the test question.

core/modules/book/book.module
542:    $options = array($nid => '<' . t('create a new book') . '>') + $options;
546:    $options = array(0 => '<' . t('none') . '>') + $options;

core/modules/forum/forum.admin.inc
297:  $options[0] = '<' . t('root') . '>';

core/modules/image/image.field.inc
294:    '#empty_option' => '<' . t('no preview') . '>',

core/modules/system/system.admin.inc
1670:  $period[0] = '<' . t('none') . '>';

core/modules/taxonomy/taxonomy.admin.inc
723:    $options = array('<' . t('root') . '>');

Aha! So #10 actually calls the approach of our patch into question here. Perhaps we should just be moving the "special" characters outside and concatenating them with the t().

I do still think that making None consistent is a good idea, and obviously we still need to patch the <br /> tags.

Updates per #10 and #11

1. Should we also standardize these "none" strings while we're changing them? (from #10)?
   

   core/modules/book/book.module
   546:    $options = array(0 => '<' . t('none') . '>') + $options;
   
   core/modules/system/system.admin.inc
   1670:  $period[0] = '<' . t('none') . '>';
   

2. Maybe we should also open a followup issue wherein we bikeshed on our use of these punctuation marks to denote "special" select options. Personally, I am not fond of the angle brackets--they look like tags--and there may also be an accessibility question.

   Also related: our use of hyphens for "indentation" to denote hierarchy in select boxes. See:

   • #30993: Scaleable/themeable taxonomy selection widget
   • #12089: Better method of showing forum containers in form
   • #211494: Usability: Unify select option formatting
   • #1001728: Field widget "Select list" option of existing instances is confused with empty "- Select -" option of new instances
3. Also, does <front> also cause translation problems? We shouldn't change that here because that has much larger implications; it's an actual token we use and not just a placeholder string in select boxes. If it does cause problems, that'd be a separate followup issue (though it seems surely that would have come up before)...
4. I also asked Gabor to take a look at this issue and see if he had any suggestions regarding if/how it could be tested.

Would be great to have some consistency. The patch suggests we modify to -none- at places. Is this to be consistent with something else? Also, what kind of testing feedback are you looking for? I don't understand that question.

I thought few times and have a question.

eg.

<unsafe>
<' . t('unsafe') . '>'

what's the different between these strings.

If we give a warning message and let admin to select import or not, would it be a problem?

comment #6 ~ #10 removed/hided at #1020842: Error messages when importing translated strings fails are not helpful at all, do you know anyone working on it?

@droplet: t('<unsafe>') is problmatic, because string are translated / assumed as HTML, and unsafe is not a valid HTML tag.

I agree that we should eliminate t('<none>'), but not because they are rejected by the import system, but because the surrounding brackets are not part of the text itself. The former issue (whether we should allow important unsafe HTML) is really a separate issue - let's keep that discussion in #514926: translated strings shouldn't be validated.

I support comment #15 about finding a standard approach so that we don't mix t('<none>') and t('- None -') in core, preferably based on a theme function or similar.

Right, just let translators translate the text and how it is presented whether with brackets or hyphens is a different question.

#12: untranslatable-strings-1317884-12.patch queued for re-testing.

Hi,
here is a new patch adapted to the last codebase.
Hopefully it went green !

All changes look good.

Committed to 8.x. Thanks!

Thanks!

ahh. I've grepped git source and git log, can't find any changes ?

No changes:
http://drupalcode.org/project/drupal.git?a=search&h=HEAD&st=commit&s=131...
http://drupalcode.org/project/drupal.git/blob?f=core/modules/image/image...

But it may not safe to commit:
http://drupal.org/node/514926#comment-6497228

The reason that changes are invisible maybe the moving files.

diff --git a/core/modules/field/modules/number/number.module b/core/modules/field/modules/number/number.module
index b3f5615..5fe30c5 100644
--- a/core/modules/field/modules/number/number.module
+++ b/core/modules/field/modules/number/number.module
@@ -214,7 +214,7 @@ function number_field_formatter_settings_form($field, $instance, $view_mode, $fo

Number module has moved to other place. And I didn't find such translation strings '', inside t() through UI 'admin/config/regional/translate/translate' filtering string ''.

So I think it's fine here.

Actually it looks like @droplet is correct; I can't find any commit for this issue. git log | grep "1317884" returns nothing. And:

[lorentz:drupal | Sun 09:33:59] $ grep -r "<none\>" *
core/modules/block/block.install:    'description' => 'Custom title for the block. (Empty string will use block default title, <none> will remove the title, text will cause block to use specified title.)',
core/modules/image/image.module: *   If TRUE a <none> option will be inserted in the options array.
core/modules/image/image.module:    $options[''] = t('<none>');
core/modules/locale/locale.pages.inc:      $empty_option = isset($filter['options'][$filter['default']]) ? $filter['options'][$filter['default']] : '<none>';
core/modules/locale/locale.pages.inc:  $langname = isset($langcode) ? $languages[$langcode]->name : "<none>";
core/modules/number/lib/Drupal/number/Plugin/field/formatter/DefaultNumberFormatter.php:      ''  => t('<none>'),
core/modules/views/lib/Drupal/views/Plugin/views/relationship/GroupwiseMax.php:    $views = array('' => '<none>');

#22: untranslatable-strings-1317884-22.patch queued for re-testing.

This is the rerolled patch.

There're still some other sort of strings needed to change.
After apply the patch

John@JOHN-PC /d/apache/drupal8 (non-tranalste)
$ grep -r '<none>' core
core/modules/block/block.install:    'description' => 'Custom title for the block. (Empty string will use block default title, <none> will remo
ve the title, text will cause block to use specified title.)',
core/modules/image/image.module: *   If TRUE a <none> option will be inserted in the options array.
core/modules/locale/locale.pages.inc:      $empty_option = isset($filter['options'][$filter['default']]) ? $filter['options'][$filter['default'
]] : '<none>';
core/modules/locale/locale.pages.inc:  $langname = isset($langcode) ? $languages[$langcode]->name : "<none>";
core/modules/number/lib/Drupal/number/Plugin/field/formatter/DefaultNumberFormatter.php:      ''  => t('<none>'),
core/modules/views/lib/Drupal/views/Plugin/views/relationship/GroupwiseMax.php:    $views = array('' => '<none>');

To keep consistency, I guess we need to change all these '<none>' to '- None -'. Of course, some are for the import error concern, e.g.,
core/modules/number/lib/Drupal/number/Plugin/field/formatter/DefaultNumberFormatter.php: '' => t('<none>'),

I'm not sure is it appropriate to change all to '- None -' in #35. Anyway, a final patch attached.

interdiff-34-37.txt indicates all the changes according to #35.

removed needs reroll tag

+++ b/core/modules/block/block.installundefined
@@ -128,7 +128,7 @@ function block_update_8003() {
-    'description' => 'Custom title for the block. (Empty string will use block default title, <none> will remove the title, text will cause block to use specified title.)',
+    'description' => 'Custom title for the block. (Empty string will use block default title, '- None -' will remove the title, text will cause block to use specified title.)',

This causes the notices due to the string being terminated :) '...'- None -'...' :)

just fixed that one line by removing the 's

@Gábor Hojtsy, ha, yeah, I missed that!
Wish #41 will pass~

#41: untranslatable_strings-1317884-41.patch queued for re-testing.

#41 is out of date.

Thanks for the reroll.

Great work @smiletrl!

Committed and pushed to 8.x. Thanks!

Woot, thanks!

some instances were missed. See #421118-48: [Meta] Standardize capitalization on actions