currency shouldn't use a simple space, use nbsp instead.

[estani]

Summary

The problem was already mentioned in apidock in 2008.
There is no valid scenario where a symbol should be separated from the amount it describes, it's as bad as breaking the number itself, so this behavior should be finally addressed, imho.

Steps to reproduce

Use some locale where the currency symbol has a space in it, like de

HTMLEntities.new.encode(Class.new.extend(ActionView::Helpers::NumberHelper).number_to_currency(12, locale: 'de'), :named)
=> "12,00 €"

Because of the simple space the semantic is:

if needed is ok to separate "12,00" from "€"

which is not true.

Expected behavior

The space need to be considered part of the currency, so it should be a non-breaking space.
The expected result should be: 12,00 €

Work around

Replacing the space by nbsp would sort it out (a proven work around for over 11 years):

HTMLEntities.new.encode(Class.new.extend(ActionView::Helpers::NumberHelper).number_to_currency(12, locale: 'de').gsub(' ',"\u00A0"), :named)
=> "12,00 €"

Proposal

replace the format: "%n %u" of the locale (example of de:
https://github.com/svenfuchs/rails-i18n/blob/master/rails/locale/de.yml#L159)

by format: "%n\u00A0%u"

[pama]

I don't understand why translations should address formatting. For specific apps, we can customize our own .yml file, or use a span with white-space:nowrap;

[dvodvo]

Adding a span is possible, but still clutter.
i18n does address formatting, but is a hack, and incomplete. The seperator between number and unit is a universal concern for a site and should be consistent across all languages.

This is truly of the realm of the helper.

based on my reading, the number to currency method has :format attribute which should allow format: "%u[something for   ]%n". This obviously has wider implications on all the helpers, for which I have insufficient perspective.

Creating a distinct attribute would create clutter, but may be the proper path to follow given the non-breaking space handling consequences.

[ruurd]

@pama because i18n and l10n are closely tied to presentation. I consider localisation as responsible for correctly formatting various pieces of data - for example money - in a correct form for that particular locale. An amount with a space would have to be presented with a non-breaking space if that is what that particular locale requires. In addition it is regarded as bad style to have dangling currencies in a text. Reason enough to adjust and/or expand rails-i18n in such a way that it properly deals with money amounts (and other cases where a non-breaking space is relevant, for example where it deals with storage and percentages)

[pama]

I disagree.

Presentation is a "convention". Conventions depend on the norm we want to adopt in our apps.

Web is different from documents, and most of the time we don't have enough space to show all our data. I don't see a big issue to render 100 Kg in different lines because we lack space to render a table column, or because the user decided to use the browser zoom to get bigger text fonts. If that is an issue, it's a lot easier to fix that with CSS, than changing all the YAML files.

Plus, I might be wrong but I see this repository as a translation of the original en.yaml file (present in the rails source code). I think that the rails options are a good compromise between minimal format decisions and flexibility.

To better understand my point of view, read the following examples. It will be very difficult to please everyone:

in The International System of Units, 9th edition

in The International System of Units, 8th edition