WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#15887 closed enhancement (fixed)

Capital letters for writing the word "Error"

Reported by: doktorbro Owned by: markjaquith
Milestone: 3.3 Priority: normal
Severity: minor Version: 3.1
Component: Warnings/Notices Keywords: i18n has-patch
Focuses: Cc:

Description

You can find many places in the i18n with the word "ERROR" or "Error". Example:

msgid "<strong>ERROR</strong>: Please type your e-mail address."

msgid "<strong>Error:</strong> There was an error connecting to the server, Please verify the settings are correct."

The word "ERROR" doesn't exist in English, all I ever see in books is "Error" or "error". "ERROR" is bad style for people, who don't know about CSS. "Error" is absolutely enough.

The problem is, all the European translator monkeys write their version of "ERROR" with capital letters too.

So please, change "ERROR" to "Error".

Attachments (3)

15887.patch (17.4 KB) - added by SergeyBiryukov 3 years ago.
t15887-Capitalize-ERROR.diff (11.1 KB) - added by JDTrower 3 years ago.
Let's be consistent in ERROR
t15887-Capitalize-ERROR-2.diff (10.0 KB) - added by JDTrower 3 years ago.
Second go at being consistent with ERROR.

Download all attachments as: .zip

Change History (23)

comment:1 SergeyBiryukov3 years ago

I don't really get it, but I'd like to try, since I'm probably one of those monkeys you are referring to :)

  1. When I write any English word using capital letters, does it cease to exist as such?
  2. What has CSS to do with it?

comment:2 SergeyBiryukov3 years ago

  • Keywords ui-feedback added

comment:3 markjaquith3 years ago

  • Milestone changed from Awaiting Review to Future Release
  • Owner set to markjaquith
  • Status changed from new to assigned

IT WOULD BE GOOD TO STANDARDIZE ONE WAY OR THE OTHER. ;-)

comment:4 valentinas3 years ago

Sergey, I don't know much about when or if it is appropriate to write in capital letters, but i believe that good practice is to keep all text in normal letters (like "Error" in the beginning of the sentence and "error" in the middle) and if you want to show them in uppercase then just apply css "text-transform".

comment:5 marcoceppi3 years ago

You don't see all capital words in dictionaries because it's not a spelling - it's a punctuation/grammatical format. All CAPITAL letters in a word typically denotes Empasis. It's not meant to be

"Good day gentle, but incorrect, user - there seems to be an error. Be a sport and type in your e-mail address"

But rather

"HEY, USER! (yelling) THERE'S A PROBLEM! ATTENTION! ERROR. Type in your email address please"

Last edited 3 years ago by marcoceppi (previous) (diff)

SergeyBiryukov3 years ago

comment:6 SergeyBiryukov3 years ago

  • Keywords has-patch added

Created the patch in case this will ever be standardized in the proposed way.

comment:7 chexee3 years ago

+1 marcoceppi. Error notices should be captalized for emphasis.

comment:8 jane3 years ago

Agreed with @marcoceppi.

comment:9 scribu3 years ago

  • Milestone Future Release deleted
  • Resolution set to invalid
  • Status changed from assigned to closed

Closing then.

comment:10 doktorbro3 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

One more time, for Latin-alphabet lovers: I don't care how you want to see emphasis in your language. All I want, that you use the CSS property <strong> to display it. Semantic web is not a buzzword. The official description is: “The strong element represents a span of text with strong importance”.

Do you know about scripts without capital letters? Yes, they exist. Hebrew, Arabic, Thai and so on. If they don't have the possibility to mark words with CSS, they don't get any chance to show the importance of a word inside the warning. Bad usability for our non-occident friends.

For now, if I use <strong> in some msgid's, wordpress displays the CSS-Tags itself inside the warning. We need to change some message procedures for making them compatible to msgid's with CSS inside. I'm sure it's all about

strip_tags()

on some places and the whole world smiles. So please, don't ignore the semantic web.

comment:11 scribu3 years ago

  • Keywords ui-feedback removed
  • Milestone set to Future Release

I agree that if we want to emphasize the error, it's better to use CSS.

comment:12 follow-up: dd323 years ago

If there are any places where ERROR is used at the start of a string without strong tags, then yes, it does need to be changed to be consistent. I'd also argue that any which use "Error" should also be updated to be consistent.

I see one case in the attached patch where <strong> is not included.

My vote would be to standardise on ERROR, I'm sure we do use Error in a few locations.

comment:13 in reply to: ↑ 12 doktorbro3 years ago

Let me show you my simple solution. Save the code below as HTML file:

<!DOCTYPE html>
<html lang="my">
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
	<title>Error international</title>
	<style type="text/css">
		strong:lang(en) { font-weight: normal; text-transform: uppercase; }
		strong:lang(he) { font-weight: bold; }
		strong:lang(my) { font-weight: normal; color: red; }
	</style>
</head>
<body>
	<div lang="en">
		<p><strong>Error:</strong> English style is uppercase.</p>
	</div>

	<div lang="he">
		<p><strong>Error:</strong> Hebrew style is bold.</p>
	</div>

	<div>
		<p><strong>Error:</strong> My style is red.</p>
	</div>
</body>
</html>

As you can see in Firefox and Chrome, the attribute lang controls the style of the element strong. Note the line 2 where I define the language of the whole document. That affects my red error style only.

Now we have to do 3 things:

  1. Use CSS element strong to mark important words, like “Error” or “Warning”.
  2. Define CSS depending on language of the document.
  3. Make sure display procedures are ready for CSS.
Last edited 3 years ago by doktorbro (previous) (diff)

comment:14 dd323 years ago

The WordPress files are in (US) English, This means all strings inside WordPress will be in a US English format.

Translations can do whatever they please with these strings.

A Translation can already convert '<strong>ERROR:</strong> something' into 'something <em>(error)</em>' if thats how their locale treats messages with that tone.

I see no reason for anything other than standardising the way error's are referred to in strings that needs to be done here to support other languages...

If the problem is that translations are being incorrectly done due to translators not understanding how to translate English text into whatever language they're translating it to.. then they need education.. Monkey, ape, or super-human being..

For now, if I use <strong> in some msgid's, wordpress displays the CSS-Tags itself inside the warning

HTML Tags may be striped, or displayed inline in some locations, it will all come down to the particular string, and where'd being used; In general, you can include HTML in translated strings, however, if it's being output as part of a error message (for example in XML-RPC) the client may not support HTML.

We may also be over-escaping data in some locations, We do this for security reasons most of the time, So if something is being escaped that shouldn't be, You need to raise a bug about the exact string and where it's occuring to allow us to modify the code in question to allow translations to happen properly.

I'm sorry that I'm completely against your suggestions here, my only reason is that I believe that there is a better way to achieve it in this case than modifying the current practices...

comment:15 doktorbro3 years ago

Dion, yes, they need education. But you can set a good example by writing correct English and using CSS for markup wherever possible.

HTML Tags may be striped, or displayed inline in some locations, it will all come down to the particular string, and where'd being used; In general, you can include HTML in translated strings, however, if it's being output as part of a error message (for example in XML-RPC) the client may not support HTML.

I understand the complexity of the wordpress. But in cases like

'<strong>ERROR</strong>: Enter a username or e-mail address.'

the message appears as HTML return only. And you still put markup inside the word itself. This is wrong.

So if something is being escaped that shouldn't be, You need to raise a bug about the exact string and where it's occuring to allow us to modify the code in question to allow translations to happen properly.

I promise I will raise a bug next time I see it.

JDTrower3 years ago

Let's be consistent in ERROR

comment:16 JDTrower3 years ago

In my attached patch, I updated every instance of "Error:" to be "ERROR:" In most places, I wrapped "ERROR" in strong tags. However, there were a few places that were unclear as to whether or not HTML tags could be used, for example:
wp-admin/includes/class-ftp.php

$this->SendMSG("ERROR: Cannot connect to remote host \"".$this->_fullhost." :".$this->_port."\"");

wp-admin/includes/class-wp-importer.php

fwrite( STDERR, "ERROR: can not determine blog_id from $blog_id\n" );

wp-includes/class-snoopy.php

$this->error = "ERROR: cURL could not retrieve the document, error $return.";

wp-includes/ms-functions.php

return __( 'ERROR: Site URL already taken.' );

I also brought up on IRC about whether words like "Warning" and "Caution" (maybe "Notice" as well) needed to be in all caps for consistency purposes. JJJ responded with "For some reason, I don't think Warning or Caution should be capitalized. I feel like those words alone already mean something important, and capitalizing them runs the risk of overemphasizing them."

If the examples above can include strong tags, I'll add them in and recreate the patch. Also, if we decide to capitalize words like "Warning" and "Caution" I'll create a patch that does that.

This patch, capitalizes the word Error in the code. If we want to use CSS text-transform: uppercase I'll incorporate that method.

comment:17 dd323 years ago

wp-admin/includes/class-ftp.php and wp-includes/class-snoopy.php are external libraries, we generally don't change the strings inside these files, nor are they translated (In both cases, adding <strong> tags there would probably not achieve anything either as Snoopy is deprecated, and that error string fron ftp shouldn't be shown I don't believe).

wp-admin/includes/class-wp-importer.php should be able to support <strong> tags.

wp-includes/ms-functions.php should be able to support strong tags, but will need to be triple checked.

For what it's worth, I agree that Warning, Caution, and Notice should not be capitalised.

comment:18 JDTrower3 years ago

Thanks, dd32. I'll be uploading a new patch to not include changes to the external libraries and to add the strong tags in the remaining places.

I'm fine with leaving Warning, Caution, and Notice as they are. Just wanted to ask, because if the consensus was to change them, it would make sense to do it at the same time that we change Error.

Maybe I'm just not seeing it, but I'm trying to test the addition of the strong tags in wp-includes/ms-functions.php but I can't seem to find where to test to generate one of those errors.

JDTrower3 years ago

Second go at being consistent with ERROR.

comment:19 markjaquith3 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In [18841]:

Be more consistent with ERROR: messages. fixes #15887

comment:20 SergeyBiryukov3 years ago

  • Milestone changed from Future Release to 3.3
Note: See TracTickets for help on using tickets.