Implementation of the localized Quantities and Units' name.

[yannickrondeau]

Problem
The library offers method to get the unit abbreviation localized. However, there is no way of localizing the quantity and unit's name. It would help if the library could handle localization of them "built-in".

Solution
Currently the localization is handled in Json files under the Localization field. The idea would be to duplicate this field for each properties that defines names so each names can be localized.

Here is an example of the localization within a json file.

{
  "Name": "Length",
  "BaseUnit": "Meter",
  "XmlDoc": "Many different units of length [...] is sub-divided into SI and non-SI units.",
  "Localization": [{ "Culture": "fr-CA", "Name":  "Longueur" }],
  "Units": [
    {
      "SingularName": "Meter",
      "PluralName": "Meters",
      "FromUnitToBaseFunc": "x",
      "FromBaseToUnitFunc": "x",
      "Prefixes": [ "Nano", "Micro", "Milli", "Centi", "Deci", "Kilo" ],
      "Localization": 
      [
        { "Culture": "en-US", "Abbreviations": [ "m" ] },
        { "Culture": "fr-CA", "SingularName": "Mètre", "PluralName": "Mètres" }
      ]
    }
  ]
}

This feature could be linked to #371. The public properties and the abstract class could implement the methods and properties to access the localized names. In a similar way of the abbreviation.

[angularsen]

I think this proposal looks pretty good and something we can extend upon. I like how Localization consistently acts as an override of the default names, when defined for a given culture.

Just to be clear on the terminology, we define Length as a quantity and Meter as a unit.

Did you intentionally put "Longueur" in an array, so that you expect to define multiple quantity names for a culture?

[yannickrondeau]

It wasn't intentional, it should indeed be a value, defining multiple name for one culture wouldn't make much sens.

I updated the description with the new terminology (Thanks). I will be working on the above implementation as a proof of concept. I know that some libraries are also localized (such as Fluent Validation) and will take a look at them to see how they did it and if we could improve from the above solution.

[angularsen]

So, what remains to decide is how to access these localized names of quantities and units. Bear in mind that we also have a base type discussion #371 going on in parallel that might influence this design.

I see two options:

Static getter methods per quantity

The advantage of this is better intellisense and a more intuitive method signature, since we can hard code the LengthUnit type.

var french = new CultureInfo("fr-CA");
Length.GetQuantityName<Length>(french); // "Longueur"
Length.GetUnitNameSingular(LengthUnit.Meter, french); // "Mètre"
Length.GetUnitNamePlural(LengthUnit.Meter, french); // "Mètres"

Implemented with straight forward static methods:

 // Culture defaults to CurrentUICulture
class Length
{
  public static string GetQuantityName(IFormatProvider provider = null) { }
  public static string GetUnitNameSingular(LengthUnit unit, IFormatProvider provider = null) { }
  public static string GetUnitNameSingular(LengthUnit unit, IFormatProvider provider = null) { }
}

Instance getter methods in UnitSystem

The advantage of this is less code and binary size, since we only need one method instead of one for each of the 60+ quantities.

var unitSystemFrench = UnitSystem.GetCached("fr-CA");
unitSystemFrench.GetQuantityName<Length>(); // "Longueur"
unitSystemEnglish.GetUnitNameSingular(LengthUnit.Meter); // "Mètre"
unitSystemEnglish.GetUnitNamePlural(LengthUnit.Meter); // "Mètres"

Implemented similar to GetDefaultAbbreviation():

public string GetUnitNameSingular<TUnitType>(TUnitType unit)
    where TUnitType : /*Enum constraint hack*/ struct, IComparable, IFormattable
    { /* look up unit name similar to how we look up abbreviations */ }

[yannickrondeau]

Considering the #371 feature, would it be better to keep the implementation as similar as possible to the current one ? If so, I would prefer implementing it using the same behavior as the GetDefaultAbbrebiation()

[angularsen]

Sorry for slow answer.

I agree, for now let's go with UnitSystem. We can always add per quantity later that simply delegate to UnitSystem methods, but I think this will suffice. It may also help if we add a <example></example> tag in the xmldoc of the method that explains it accepts all kinds of unit enum values, such as LengthUnit.Meter and MassUnit.Kilogram.

On second look, my earlier example should be:

unitSystemFrench.GetQuantityName<Length>(); // instead of this
unitSystemFrench.GetQuantityName(QuantityType.Length); // do this

[angularsen]

Just checking in, can we help make any progress here?

[yannickrondeau]

Hi @angularsen! I started reviewing the code and the json files to see how we could achieve this. I did not have any time to continue working on this lately. I should be working on this this weekend.

[angularsen]

Awesome!

[yannickrondeau]

Just a head up here, I've been working on this on my own repository. Still got a lot to figure out, I want to make sure I understand the framework correctly. However, I think that we might be able to work something out.

I'll try to keep you updated of the progress. Currently this si not a major issue on our end, which is why I haven't got a lot of time on it.

[angularsen]

Thanks for the update, let me know if I can help in any way. -- *Andreas Gullberg Larsen* | +47 975 70 270 <+47%20975%2070%20270> | Leinsmoen 7, 7655 Verdal, Norway

[yannickrondeau]

Hi!

It's been a while since I gave news on this feature request. I've been busy lately with company stuff and couldn't work on this at all. However, it just came back on the table internally here with localization issues, therefore I started working on it again.

From what I've revised so far, the abbreviations are loaded trough the localization class AbbreviationsForCulture.cs which would require some changes to add the SingularName and PluralName property. While I want to be able to localize quantities and units, I don't think it should be mandatory. Therefore, I might need to rework a little bit this part of code so we can default the names to the quantity and unit default names already in place. Maybe @angularsen you have a better idea or I could be wrong on this.

I will give more news in the upcoming days. Again, sorry for the time it took me to get going on this.

[angularsen]

Welcome back :-) No problem, I fully understand how the interest in libs can come and go. I agree that localization should be optional, in the sense that if a culture is not defined it falls back to en-US (as we already do) and if maybe SingularName or PluralName is not defined for say French, it would fall back to en-US for the missing values. At least in my mind that is what seems the most intuitive?

--

*Andreas Gullberg Larsen* | +47 975 70 270 <+47%20975%2070%20270> | Leinsmoen 7, 7655 Verdal, Norway