Skip to content

Use of curly quotes #1700

Closed
designermonkey opened this Issue Mar 24, 2013 · 40 comments

4 participants

@designermonkey
Symphony CMS member

This is something I noticed recently when using events, and it's something that puzzled me.

Why are we using single curly quotes in our event output? It's not a standard character on any keyboard I've used, and I personally think it would be easier to use single or double quotes over curly ones.

@michael-e
Symphony CMS member

Can you post an example?

@designermonkey
Symphony CMS member

There's one on the forum.

@michael-e
Symphony CMS member

I verified this issue (with Sym 2.3). Looks very strange. We should definitely use single quotes here.

@nilshoerrmann
Symphony CMS member

In my eyes the use of curly quotes is correct because this way you can use the error messages on the frontend directly with correct typography.

@michael-e
Symphony CMS member

Happy validating then! Many websites check for strings in the frontend, and Symphony already ouputs error messages with:

  • single quotes
  • no quotes at all

So what has happened here? Have the single quotes been replaced? Everywhere?

@brendo
Symphony CMS member
brendo commented Mar 24, 2013

Introduced in 2011 in an effort to improve our typography by @eKoeS.

@nilshoerrmann
Symphony CMS member

Happy validating then

The actual problem are not the curly quotes but that we don't have unique error codes.

@michael-e
Symphony CMS member

Introduced in 2011 in an effort to improve our typography

I didn't know that. This will break a lot of websites vaildating forms using strings.

The actual problem are not the curly quotes but that we don't have unique error codes.

Which is the reason why we validate using strings. Agreed.

@brendo
Symphony CMS member
brendo commented Mar 24, 2013

The actual problem are not the curly quotes but that we don't have unique error codes.

What would some of these error codes be?

@nilshoerrmann
Symphony CMS member

Currently we have:

<message>Entry encountered errors when saving.</message>

It would be better to have:

<message id="sym123">Entry encountered errors when saving.</message>
@brendo
Symphony CMS member
brendo commented Mar 24, 2013

Where sym123 is what? We have 'missing' and 'invalid' attribute values, why aren't these used? What additional codes would be useful? Or is this just a general comments that extensions should be able to create them?

@nilshoerrmann
Symphony CMS member

There are situations where missing and invalid are not sufficient enough to identify the actually error, see symphonycms/members#194. We currently work around that by checking the error messages which might change from version to version.

Event ids would be an extension to the currently used two values missing and invalid similar to HTTP status codes.

@brendo
Symphony CMS member
brendo commented Mar 24, 2013

Ah I remember that issue. I think it's something we can definitely solve

@designermonkey
Symphony CMS member

I have already started working on documenting simple error codes for this exact problem, using standard HTTP error codes as a base.

I have loads of ideas for Events that I want to propose, which will lead to an extension too to manage error output with @michael-e's Members Forms, and @nickdunn's Form Controls.

I want to try and write a standard for custom evnts to follow, where they can use a pre-defined set of constants to output codes, and even messages if need be, so that custom events would be quicker to develop, and to allow us to update error messages in one place if we need to.

@nilshoerrmann
Symphony CMS member

What about creating error ids automatically like so:

$message = 'Entry encountered errors when saving.';
$id = hash('crc32b', Lang::createHandle($message));

The result in the XML would look like this:

<message id="f81dd09b">Entry encountered errors when saving.</message>

The only thing we'd have to make sure is that the hash is created using the original English message, before it gets translated.

@brendo
Symphony CMS member
@nilshoerrmann
Symphony CMS member

But they will break right now as well because we rely on string comparisons. The problem in this context is, that currently these strings are localised so they change as soon as you switch the system language. My idea above would ignore small changes like punctuations or upper and lower case changes be the base for the hash is the message handle.

What about the following:

  • Filters as expected to add an event id. (Or event-type? Not sure, but that the term the core email filter uses.)
  • If a filter does not return an id, we generate a hash.
@brendo
Symphony CMS member
brendo commented Mar 25, 2014

I guess what I was leaning towards is in future, I don't want us updating the error message to change the hash. For example, if the error is Entry encountered errors when saving., then you'd say this would be referred to as E1S. In future then, we can updated the error message and in the XSLT, developers wouldn't have to change anything. Essentially all they care about is that it's an entry saving error, not what the actual text is (as they may be overriding it anyway).

@nilshoerrmann
Symphony CMS member

@michael-e: You are by far the most experienced Symphony developer when it comes to front-end forms. Am I right, that this more or less boils down to an extension issue (namely Members, see symphonycms/members#194). I think the few core event results are unique already.

If that's so, it would be fine to close this issue because curly quotes and changed error messages won't matter from a core point of view: the statuses invalid, error etc. are distinct and thus sufficient.

@michael-e
Symphony CMS member

Yes, I agree that for core events the available statusses are sufficient. But I have always argued against curly quotes in error messages, and I still would strongly suggest to not use them. Like @designermonkey said, it's not a standard character. Most people wouldn't even know how to write them.

Some of you may know that I have been working as a (print) journalist for many years, so I know a bit about typography. And in print, I would always try and use typographically correct quotes and apostophes. On websites, things are different. Your authors won't know how to write these quotes, so why the hell would an error message in your XML need them? If you want, create your own error messages in the frontend.

Feel free to close this issue if you are sure that the use of curly quotes in XML is tolerated by the majority of developers. You won't get my vote, however.

@nilshoerrmann
Symphony CMS member

The reason for the introduction of curly quotes was that the default workspace uses error messages in the front-end directly.

On websites, things are different.

Nothing is really different there actually :) But I understand what you mean.
Personally, I'd say, if these message where only reports for the developers, ignore typography. But if Symphony itself promotes the usage of the messages in the front-end, we should make sure the typography is correct.

@michael-e
Symphony CMS member

These messages are in event XML, so they are intended for developers. So if one thinks that the default workspace needs curly quotes in frontend error messages (which it doesn't, because it attempts to teach more important things), you might still fix it over there.

You will not convince me that curly quotes must be in „machine responses“. (Please note the German curly quotes here, just as a proof that I can write them.)

@designermonkey
Symphony CMS member

I agree with Michael here, they aren't directly output to the front-end without developer intervention, so we should use developer language, and the available keys on a keyboard without having to learn how to gain access to different quote types.

If a developer decides that curly quotes or any other kind are required, they should add them; This is system/developer level stuff IMO.

@nilshoerrmann
Symphony CMS member

The thing is that Symphony actually translates these messages in order to allow the usage in the front-end. (And please note that in the context of this thread, even in German the usage of British quotes would be correct, not the German ones :P)

@designermonkey
Symphony CMS member

I feel a bickering arising here ;P

@nilshoerrmann
Symphony CMS member

I understand your point. But the actual issue you are raising is not about curly quotes but about public (visitor) versus private (developer) messages. Symphony simply doesn't treat these messages as private (otherwise they should not be translated etc.).

I feel a bickering arising here ;P

I couldn't resist :)

@nilshoerrmann
Symphony CMS member

The bottom line:

  1. we should either leave things as is
  2. or we should remove translations and curly quotes from the event messages and we should make sure the default workspace doesn't push messages to the front-end.
@nilshoerrmann
Symphony CMS member

Any volunteers for no. 2?
Otherwise I'll close this issue.

@michael-e
Symphony CMS member

As I already said:

Feel free to close this issue if you are sure that the use of curly quotes in XML is tolerated by the majority of developers. You won't get my vote, however.

What about you, John? Do you think that we should keep the curly quotes?

@nilshoerrmann: I don't agree with your latest comment. I don't feel that you must remove translations just because you use straight quotes. And, as stated above, the default workspace teaches much more important things, so it doesn't give a damn about these quotes.

@nilshoerrmann
Symphony CMS member

It's the only place in the XML that I am aware of that is translated and the removal would make clear that it is a system message meant for developers.

@designermonkey
Symphony CMS member

Curly quotes caused me a headache when string matching for the Members extension. I do think they need to be normalised, yes.

I just don't know when I will have the time to do it.

@nilshoerrmann I don't think that we have to go to such grave lengths to make a decision before you close the issue. Text can be translated, and it should be; If the developer has chosen the language for the system, then it should read in that language. This is simply about easily accessible characters for the vast majority of developers.

@michael-e
Symphony CMS member

Well, of course we might remove them from translation. I remember that one day my frontend forms' error messages broke just because I tried German in the backend. :-)

Since that time my backend is English. Always. Maybe my issue was just Members related, as mentioned above, I simply don't remember.

But this is just a detail. The main question is "stick to curly quotes or not".

@nilshoerrmann
Symphony CMS member

Text can be translated, and it should be; If the developer has chosen the language for the system, then it should read in that language. This is simply about easily accessible characters for the vast majority of developers.

Please keeps in mind that we don't translate anything in the XML beside the event messages. What you are talking about is a full localisation of the system which would be a paradigmatic shift: English was always defined as the developer language. Yes, we do translate the UI completely for consistency reasons, but that's all. If the XML was translated, strings like handle etc. would have to be translated as well, which would of course break site if you switch languages. It's not practicable for a Symphony like Symphony.

So in terms of consistency, if event messages are only used by developers internally, they should not be translated because we don't translate other strings in the XML output.

@brendo
Symphony CMS member
brendo commented Apr 1, 2014

Guys, I've gone back to the original problem that @nilshoerrmann was trying to solve, having unique error codes for each message. What I've committed is complete for 'now', but definitely has room to grow in future releases, the main gap being individual filter errors. In the meantime, there is enough information now to construct your own messages:

Class EventMessages {

    const UNKNOWN_ERROR = 0;

    const ENTRY_CREATED_SUCCESS = 100;
    const ENTRY_EDITED_SUCCESS = 101;
    const ENTRY_ERRORS = 102;
    const ENTRY_MISSING = 103;

    const SECTION_MISSING = 200;

    const FIELD_MISSING = 301;
    const FIELD_INVALID = 302;

}
<new-event result="error">
    <message message-id="102">Entry encountered errors when saving.</message>
    <title label="Title" type="missing" message-id="301" message="‘Title’ is a required field." />
    <post-values />
</new-event>

As I said, simple, but it'll do the job :)

@nilshoerrmann
Symphony CMS member

Thanks, Brendan! That's a huge step.

@brendo brendo added this to the 2.4 milestone Apr 1, 2014
@michael-e
Symphony CMS member

Still missing a decision here if the curly quotes should be removed. :-)

@nilshoerrmann
Symphony CMS member

I decided to opt for no. 1 :)

… we should either leave things as is …

Please just send a pull request, if you think this needs to be changed.
No need to leave this open.

@brendo
Symphony CMS member
brendo commented Apr 1, 2014

Still missing a decision here if the curly quotes should be removed. :-)

Curly quotes can stay. The error message abstraction above means that it really doesn't matter what Symphony outputs anymore.

@designermonkey
Symphony CMS member

Just a thought here....

Would it not be better to output the curly quotes as the XML numeric entity? It would be easier to match on that the actual quote character.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.