Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apostrophe not being displayed correctly in MessageSource [SPR-9169] #13807

Closed
spring-issuemaster opened this Issue Feb 24, 2012 · 5 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Feb 24, 2012

marc schipperheyn opened SPR-9169 and commented

When a list of key value pairs for MessageSource contains an apostrophe, it is not displayed.

e.g.
ui.nophotos=Nog geen foto''s geplaatst
displays "Nog geen foto''s geplaatst" INCORRECT

ui.nophotos=Nog geen foto''s geplaatst door {0}
displays "Nog geen foto's geplaatst door Marc" CORRECT

ui.nophotos=Nog geen foto's geplaatst
displays "Nog geen fotos geplaatst" INCORRECT

if there is no args replacement, Spring will display two apostrophes.

This may seem trivial to an English speaker, but in other languages, this is a nightmare. It's also inconsistent.


Issue Links:

  • #13989 Apostrophe in MessageSource text leads to {0} not being replaced
@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented May 15, 2012

Chris Beams commented

This issue is closely related to #13989; both should be addressed simultaneously if possible. I've asked Marc to consider adding a reproduction project (see comments in #13989).

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented May 15, 2012

Balázs Bessenyei commented

Unfortunately it is consistent. http://static.springsource.org/spring/docs/3.0.x/api/org/springframework/context/MessageSource.html uses Java standard http://docs.oracle.com/javase/6/docs/api/java/text/MessageFormat.html to parse the input. Since that contains an entire section of warning about this one.

"Warning:
The rules for using quotes within message format patterns unfortunately have shown to be somewhat confusing. In particular, it isn't always obvious to localizers whether single quotes need to be doubled or not. Make sure to inform localizers about the rules, and tell them (for example, by using comments in resource bundle source files) which strings will be processed by MessageFormat. Note that localizers may need to use single quotes in translated strings where the original version doesn't have them."

Since it is a documented behavior of MessageFormat it would be problematic to fix without rewriting the component.

In our case the workaround was adding the <property name="alwaysUseMessageFormat" value="true" /> to the MessageSource bean definition. http://static.springsource.org/spring/docs/1.2.x/api/org/springframework/context/support/AbstractMessageSource.html#isAlwaysUseMessageFormat()

This means the String will be parsed using MessageFormat rules even if no parameter is present so all standard apostrophes need to be escaped.

This solution also works with STL FMT message solution. We have not tested it with the Spring taglib equivalent, since it uses the same MessageSource implementation it should work in that case as well.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented May 15, 2012

marc schipperheyn commented

Ok, AFAIC the behaviour is very inconsistent because the behaviour is different when there is a {0} variable in play

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented May 15, 2012

Balázs Bessenyei commented

It is consistent with FMT:Message and Spring:Message taglibs behavior, which is documented on Java and Spring side (java.text.MessageFormat). Changing this would break already existing applications and localizations with the current applications, the above mentioned "workaround" appears to be address the problem. Fixing the inconsistent behavior should be done as an opt-in basis, which already exist.

I agree that the Java MessageFormat behavior is extremely unintuitive, but it is documented and there is an opt-in solution on Spring side to fix it, without breaking all current localizations. Of course it is the Spring developers decision to try to address it (probably by recreating the JDK MessageFormat with a more consistent behavior) or live with the mentioned solution (document it more clearly in the API doc).

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Jan 12, 2019

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.