#15887 closed enhancement (fixed)
Capital letters for writing the word "Error"
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| 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)
Change History (24)
#3
@
14 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. ;-)
#4
@
14 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".
#5
@
14 years ago
You don't see all capital words in dictionaries because it's not spellings 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"
#6
@
14 years ago
- Keywords has-patch added
Created the patch in case this will ever be standardized in the proposed way.
#9
@
14 years ago
- Milestone Future Release deleted
- Resolution set to invalid
- Status changed from assigned to closed
Closing then.
#10
@
14 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.
#11
@
14 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.
#12
follow-up:
↓ 13
@
14 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.
#13
in reply to:
↑ 12
@
14 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:
- Use CSS element strong to mark important words, like “Error” or “Warning”.
- Define CSS depending on language of the document.
- Make sure display procedures are ready for CSS.
#14
@
14 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...
#15
@
14 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.
#16
@
14 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.
#17
@
14 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.
#18
@
14 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.
I don't really get it, but I'd like to try, since I'm probably one of those monkeys you are referring to :)