Different abbreviations for volume unit Liters used

[geseru]

Not the same abbreviation for Liters is used in the whole library. Sometimes it's an uppercase letter "L", sometimes a lowercase letter "l" is used.

Some examples: Volume Liter => abbreviation "l" Volume flow LiterPerMinute => abbreviation "L/min" Volume flow LiterPerHour => abbreviation "L/h" Volume flow LiterPerDay => abbreviations "l/day", "L/d", "LPD" ...

The same abbreviation should be used in the whole library.

[Brunni]

According to SI Symbols both l and L are correct: https://en.wikipedia.org/wiki/International_System_of_Units

According to CEFACT rec20 UN standard the lower case variant is used.

According to a US National Institute website: https://physics.nist.gov/cuu/Units/outside.html#:~:text=Thus%2C%20although%20both%20l%20and,approved%20symbols%20for%20the%20liter.

The liter in Table 6 deserves comment. This unit and its symbol l were adopted by the CIPM in 1879. The alternative symbol for the liter, L, was adopted by the CGPM in 1979 in order to avoid the risk of confusion between the letter l and the number 1. Thus, although both l and L are internationally accepted symbols for the liter, to avoid this risk the preferred symbol for use in the United States is L. Neither a lowercase script letter l nor an uppercase script letter L are approved symbols for the liter.

[angularsen]

I too favor uppercase "L", so I propose we change them all in #982 ? Parsing first tries case-sensitive, then falls back to case-insensitive, so it should be fairly backwards compatible.

[hughesjs]

The standard for units, to my understanding, is that unless it's named after someone, it's lower case. Sure L might be used about as widely as l but that's a side-effect of how common the usage is amongst laypeople. I feel that when there's the potential to use two "equally correct" abbreviations, we should follow convention.

[angularsen]

I'd like to land on a convention here, but I don't want this to come down to personal preferences, mine the least. I want to follow industry standards, however it seems to be split on American vs European/international.

@Brunni listed 3 standards:

• SI (European/international), uses "litre" and lowercase "l".
• UN/CEFACT (European) uses "litre" and lowercase "l".
• NIST/CGPM (American), uses "liter" and uppercase "L".

Are there more sources we can use to make a decision here?

Library already favors American and US English conventions

This library has generally been following US naming conventions, such as "liter" instead of "litre". I guess this has roots in my personal preferences when creating the first units of the library, preferring US English and US naming conventions.

I don't want to change this, as this naming convention has been in place for close to 10 years now and I can't recall any requests to change "liter" to "litre".

It would also be a breaking change for the majority of the library consumers, which is a hard no for me.

It comes down to

Having named the units "liter", should we use "L" or "l" as the primary abbreviation for ToString()? We already support both for parsing.

My take is that American standards and laypeople communicating in US English prefer "liter" and "L", while European/international standards prefer "litre" and "l". The above standards seems to support this.

Based on this I propose to make it uppercase "L". Do you agree with the reasoning?

[hughesjs]

If you want to land on a standard, go with SI. I don't think the spelling particularly matters (since the brain reads whole words, it doesn't care that much about small spelling differences), but for the abbreviations, it makes far more sense to standardise on the actual international standard rather than deciding to go with the Americanism. The whole point of having an international standard is to put an end to ambiguities like this and make sure that things work for the largest percentage of the global population.

I also note that those Americans that I have worked with in technical fields tend to follow SI more closely than laypeople. Finally, if someone is dealing with litres as an American, chances are they're already more versed with SI than most. If we were talking about imperial units, I'd be more inclined to say go with the NIST capitalisation schema because it's only Americans that use them anyway. It's worth noting that Americans refusing to go with SI has, quite literally, crashed satellites.

I guess the other options is adding some sort of localisation option. This would probably be my preferred option, but it's a bit more work. I'd be inclined to say read the locale of the current environment, if it's en_US use NIST standards and otherwise use SI/ISO standards, potentially adding an overload that lets you take CurrentCulture (or some custom SI/NIST enum) options if you want to override that.

[angularsen]

Thank you.

I think your reasoning is sound and I also suspect most laypeople don't care much about "L" vs "l", while people in technical fields probably find "L" non-standard. However, I also think they will find the liter/l combination odd.

To summarize "liter" vs "litre" and "L" vs "l":

• Option 1 - liter/L - No change. Consistent with American standards and language.
• Option 2 - liter/l - Change "L" to "l". No breaking change (1), but also not consistent with any industry standard (2).
• Option 3 - litre/l - Change both. Consistent with international industry standards, breaking change for many.

1) Changing case of unit abbreviations is generally not a breaking change, parsing is case-insensitive if not ambiguous.

2) American standards use liter/L while international and European standards use litre/l: https://github.com/angularsen/UnitsNet/issues/1115#issuecomment-1374479034

3) Breaking change due to unit enum names like VolumeUnit.Liter being changed to VolumeUnit.Litre. We can soften the transition by having both for a period of time, marking the old one as obsolete so compile warnings give instructions to change it, before removing it in the next major version.

---

Let me ping some contributors for opinions on this: @tmilnthorp @lipchev @eriove @josesimoes @Ellerbach @bretthysuik @JKSnd

Please also cast your vote here (deadline in 5 days): https://github.com/angularsen/UnitsNet/discussions/1201

[Ellerbach]

I usually like the SI one but I do few exceptions like Litter with a capital L, the reason is simple: readability on a machine. You have to have great eyes to differentiate capital/uppercase i with lowercase l in a lot of fonts. See I and l. Which one is which one in this example? So I would keep L for this only reason.

[josesimoes]

Considering that SI allows for both upper case and lower case of letter L (precisely because of the potential confusion with the lower case and capital i) I would vote for upper case L. That way we'll be SI compliant and also improving readability.

As for litre vs liter... that's falls out of engineering scope... 😅 not being able to use Culture information I would default to English.

[lipchev]

If capitalizing the abbreviation means that "mL" would be the derived unit- then I vote for lowercase "l" (already the spellcheck is suggesting that I should be using "ml" instead) . We would normally write "g/l" and "mg/ml" instead of "g/L" and "mg/mL"- and as for the word spelling, in Bulgaria we use the American style for singular (e.g. "1 litar") and the English for plural (e.g. "2 litra(s)") - but we're not exactly known for keeping up with "standards"..

[angularsen]

I knew you guys wouldn't make it easy 😅

It seems there are no strong opinions on liters vs litres.

So let's try to put us into some buckets on casing:

• In favor of uppercase "L": @Ellerbach, @josesimoes, @angularsen
• In favor of lowercase "l": @hughesjs, @lipchev
• As long as it's consistent: @geseru, @brunni (not sure about your preference)

We're a bit few, but seeing that we are kind of split on preference I think it speaks to that there is no obvious correct solution for everyone and that options 1-3 are all viable.

I lean towards option 1 - no change, keeping it "L" and "liter" and more importantly, not introducing any breaking change on litre vs liter.

How about we instead offer a global configuration for controlling "L" vs "l" for liters? I'm not exactly sure how it would work, but it is probably doable and would only affect ToString().

[josesimoes]

Being pragmatic here: not 100% sure if it's worth the trouble of implementing that config option... I would file this under "by design" and move along with the option you choose being the most appropriate. Both are SI compliant so it will always end up on a personal preference. 😉

[tmilnthorp]

Isn't this just a localization issue? Using VolueFlow as an example we could:

• Keep the existing "en-US" as "L/min"
  • Optionally add "l/min" as another abbreviation
• Add a Localization for "en" to be "l/min"
• Make sure that the names/abbreviations are consistent for any given culture

I would keep the properties as LiterPerMinute just to avoid a code-break.

[angularsen]

Isn't this just a localization issue?

Interesting, I guess culture could play a part here.

Some challenges that come to mind with culture:

• Would we have to define many cultures in JSON? Harder to maintain/contribute. Since litre/l originates from Europe, I'm guessing many non-English cultures in Europe prefers lowercase "l"?
• Are we sure preference within a culture is that uniform? Is it perhaps more about what context/field you are working in?

not 100% sure if it's worth the trouble of implementing that config option.

Oh, it won't be me implementing it for sure. Whoever needs it the baddest will have to step up 😆

[tmilnthorp]

Would we have to define many cultures in JSON?

Only where there exists a preference for things like this. It is optional, not mandatory.

Since litre/l originates from Europe, I'm guessing many non-English cultures in Europe prefers lowercase "l"

That is my assumption. If wrong, we can always specialize for any given culture. The generic "en" fallback should "hit the most" English speaking cultures.

Are we sure preference within a culture is that uniform? Is it perhaps more about what context/field you are working in?

I am certain of nothing :zany_face:

[tmilnthorp]

I created #1209 to show what this could look like.

Let's iterate 😃

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[hughesjs]

If capitalizing the abbreviation means that "mL" would be the derived unit- then I vote for lowercase "l" (already the spellcheck is suggesting that I should be using "ml" instead) . We would normally write "g/l" and "mg/ml" instead of "g/L" and "mg/mL"- and as for the word spelling, in Bulgaria we use the American style for singular (e.g. "1 litar") and the English for plural (e.g. "2 litra(s)") - but we're not exactly known for keeping up with "standards"..

I think this is a very important point to this... Not sure how the derived units are constructed though but mL would be very jarring.

Considering that SI allows for both upper case and lower case of letter L (precisely because of the potential confusion with the lower case and capital i) I would vote for upper case L. That way we'll be SI compliant and also improving readability.

As for litre vs liter... that's falls out of engineering scope... 😅 not being able to use Culture information I would default to English.

Does it? I'm not saying you're definitely wrong, but I've never seen anything that says this.

[angularsen]

Coming in with fresh eyes here, I'll just make a decision to at least standardize on something and move one with our lives.

• Keep Liter instead of changing to Litre - mostly to not break everyone.
• Change to lowercase l in abbreviations, there seems to be a consensus that L is weird.

Decision is final unless anyone objects in 3... 2.. 1.. aaand it's merged!

Fixed in #1404 Wiki updated: https://github.com/angularsen/UnitsNet/wiki/Adding-a-New-Unit#abbreviation-naming-conventions

I made the change in v6, so you can still voice your strong opinions here before v6 exits prerelease.