Add support for i18n

[cblock]

I'd love to have i18n support for unit labels. What about switching the label definitions in the config.rb to symbols that are only looked up if one explicitly calls unit.label?

[spatchcock]

Not sure I follow.

In the present system, the labels are important as they are the canonical, unique reference for each unit. In contrast, unit symbols and unit names do not have to be unique.

Are you able to expand on your idea?

[cblock]

Sorry. I mixed up the words. I meant unit names but wrote unit labels.

Let me try it again:

• Unit labels and symbols are fine and should not be touched.
• Unit names should be subject to i18n

For yml lookups it would be good to have a unique reference (ruby symbol) that comes with each unit.
I'd say Unit#label would be a good candidate but there are some labels actually defined (e.g. '′', or '°C') that make it not so suitable.

To rephrase my question:

• Can we remove any special characters from the Unit#label and - at best - turn those Strings into Symbols?
• And can we then rewrite Unit.name() so that it looks up unit names through i18n?

[spatchcock]

Hmmm. That does sound very good, and in fact might help to accommodate this issue too: #5

My only reservation is that the existing labels were chosen to be consistent with the JScience library. I like the idea of a compatibility between the two libraries and know of at least one service which uses this feature. Perhaps we could change the labels as you say and add an optional j_science_label attribute to each unit configuration.

Removing special characters from the labels would be an improvement in it's own right too.

[cblock]

To me introducing a j_science_label attribute and changing the label seems like a good idea.

This allows to properly rework the label thing and add i18n and synonym comparison on top of it. Once done a major version bump will indicate backwards incompatibility. But users of the gem are offered a smooth migration path (switch from using label to using j_science_label instead if they require the exact label names).

[spatchcock]

Okay - good. Sounds like a plan. I can try to make the label changes in the next few days, or feel free to go ahead yourself if you need it sooner.

[cblock]

...and one more thing: In this context it would be nice to switch the unity symbol from 1 to an empty String.
75.0 1 for a unitless quantity looks quite strange to me.

[cblock]

...I'd like to help on this but I have some other deadlines to meet for the next few days. For the time being I can only promise to help testing it. For this I switchted to using quantify master branch inside quantify_mongoid gem. So just go ahead and I'll report errors as soon as they pop up downstream.

[spatchcock]

Okay, sounds fine. I go ahead over the next few days.

On the unity issue, I agree. I think there was some reason I made it like that, but can't remember. I certainly needs a non-blank label, but perhaps both the symbol and name should be empty. I'll raise a separate issue.

[spatchcock]

Hey Carsten.

I have made the changes we discussed.

labels are now Symbols, and there is a new attribute called j_science on each unit.

I have changed a few of the problematic unit labels, e.g. the degree celsius is now :deg_c instead of °C. However, there may still be some labels which are not ideal for the i18n work you have in mind. For example, some still have Greek characters (e.g. η). We can change these if required.

Also, bear in mind that labels are generated dynamically for compound units and therefore have to represent powers and denominators. This means that we still get characters such as "^" (for powers), "·" and "/" in unit labels. I have ensured that labels always use the "^" syntax for powers rather than superscript characters (this can be switched for unit symbols).

Also, we now have a mixture of formats for unit labels, most are basically unit symbols, some are abbreviated names, some have underscores and others not. I am not entirely happy with this as it seems there should be some consistency. Any suggestions are welcome.

[cblock]

Hi Andrew,

great, thanks a lot. I'll try it out now inside quantify_mongoid and then come back to you.

Cheers,
Carsten

[cblock]

Hi Andrew,

so far it looks very good. I didn't find any errors when implementing quantify_mongoid so far. I18n is not yet in place there but next on my todo list. The rest of the functionality is implemented and works nicely.
Thanks a lot for your great work!

Carsten