<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif">Thanks for the detailed report. Can you file this as a ticket?</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">The biggest problem is that the spec for constructing the fallback compound names is missing details for the times pattern, the power patterns, and the prefix patterns. The per pattern appears to be complete, <a href="https://unicode.org/reports/tr35/tr35-general.html#perUnitPatterns">https://unicode.org/reports/tr35/tr35-general.html#perUnitPatterns</a>, and some of that is described there goes also for the other complex names, such as that the fallback name construction may not work well for languages with inflections. And that the "remove the placeholder" step does require removing spaces around the {0}. Note that the "square" doesn't not work right for gendered languages because it often then needs to agree with the base unit.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">First, we need to add full descriptions for all the complex fallback names.</div><div class="gmail_default" style="font-family:times new roman,serif">Second, we need to add a test file with construction of some more complicated names. </div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">As to the details, the heuristics do have to play with the plurals, including having all but the last in a times sequence use the singular.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">We are in the process of gathering information for including gender and case, and will need heuristics for those as well. For example, my current draft has:</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif"><span id="gmail-docs-internal-guid-9e96579d-7fff-598e-ceca-d367894f71f1"><ol style="margin-top:0px;margin-bottom:0px"><li dir="ltr" style="list-style-type:decimal;font-size:10pt;font-family:Georgia;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Prefixes & powers: the gender of the whole is the same as the gender of the operand. In pseudocode:</span></p></li><ol style="margin-top:0px;margin-bottom:0px"><li dir="ltr" style="list-style-type:lower-alpha;font-size:10pt;font-family:Georgia;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">gender(square, meter) = gender(meter)</span></p></li><li dir="ltr" style="list-style-type:lower-alpha;font-size:10pt;font-family:Georgia;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">gender(kilo, meter) = gender(meter)</span></p></li></ol><li dir="ltr" style="list-style-type:decimal;font-size:10pt;font-family:Georgia;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Per: the gender of the whole is the gender of the numerator</span></p></li><ol style="margin-top:0px;margin-bottom:0px"><li dir="ltr" style="list-style-type:lower-alpha;font-size:10pt;font-family:Georgia;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">gender(gram per meter) = gender(gram)</span></p></li></ol><li dir="ltr" style="list-style-type:decimal;font-size:10pt;font-family:Georgia;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Times: the gender of the whole is the gender of the last operand</span></p></li><ol style="margin-top:0px;margin-bottom:0px"><li dir="ltr" style="list-style-type:lower-alpha;font-size:10pt;font-family:Georgia;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">gender(gram-meter) = gender(gram)</span></p></li></ol></ol></span></div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">NOTE: I'm sure that we will find cases of languages that have different strategies for dealing with the plural, gender, and case in the complex cases; so we'll undoubtedly need to refine as we go along.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font face="'times new roman', serif"><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px"><div></div></div><div style="background-color:transparent;margin-top:0px;margin-left:0px;margin-bottom:0px;margin-right:0px">Mark</div></font><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 16, 2020 at 12:27 AM Kip Cole via CLDR-Users <<a href="mailto:cldr-users@unicode.org">cldr-users@unicode.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Congratulations to those who implemented the new Unit conversion and preference data in CLDR 37. Its been a joy to implement on top of the data, and not without a few challenges :-)<br>
<br>
One area that appears undocumented, and one that is quite tricky to implement, is merging unit skeletons when outputting a string representation. I will use some examples to illustrate. All examples are using a unit value of “3” unless otherwise indicated, and all in the “en” locale.<br>
<br>
## Basic question<br>
<br>
Is there a better heuristic or some algorithm I’m missing that would improve this?  Totally ok that this is a new part of CLDR working around some heuristics is also fine. Just after the communities view of the best approach to take.<br>
<br>
## Outputting a translatable unit (meaning it has a single skeleton in CLDR)<br>
<br>
“Kilometer-per-hour” => “{0} kilometers per hour”<br>
<br>
This is a simple case and the merging of the value into the skeleton is deterministic.<br>
No issues, simple substitutions.<br>
<br>
My implementation produces "3 kilometres per hour"<br>
<br>
## Outputting a compound unit (no direct translation, composing is required)<br>
<br>
“Kilometer per second” => “{0} kilometers”, “ per “ and “{0} second”<br>
<br>
Now we have three skeletons that need to be merged. Here are the <br>
Issues as I see them:<br>
<br>
1. In order to resolve the skeleton for the denominator “second” I take the plural value for “1” (ie always singular form)<br>
2. Ignore the placeholder in the denominator so “{0} second” becomes “ second”<br>
3. String join the three skeletons<br>
4. Merge the number value into the placeholder “{0}”<br>
5. Replace the double space between “per” and “second” that arises because there is a trailing space in the “per” skeleton and a leading space in the “ second” skeleton<br>
<br>
All of this is a heuristic and I’m not at all sure it transitive for all other locales.<br>
<br>
My implementation produces "3 kilometres per second"<br>
<br>
## Outputting with an SI prefix (and/or square and cubic prefix)<br>
<br>
This is the case when the applied SI prefix has no direct translation and we are composting the translation.<br>
<br>
“Millifurlong” => “milli{0}”, “{0} furlongs”<br>
<br>
The heuristic I currently apply is:<br>
<br>
1. Since the prefix skeleton has the placeholder after the text it is merged in front of the unit<br>
2. The placeholder of the prefix skeleton is deleted => “milli”, “{0} furlongs"<br>
3. The prefix is merged to the front of the text in the unit skeleton => “{0} millifurlongs”<br>
4. Merge the number value into the placeholder<br>
<br>
The heuristic of merging the SI (or other) prefix into the unit skeleton is unlikely to be correct for all locales.<br>
<br>
My implementation produces "3 millifurlongs"<br>
<br>
## Outputting a compound unit<br>
<br>
This is where we have a unit leveraging the “times” skeleton.<br>
<br>
“Furlong light year” => “{0} light years”, “⋅”, “ {0} furlongs”<br>
<br>
1. The order of the skeletons is determined by the canonical sort order in Units.xml<br>
2. The “times” skeleton is introduced between the two units<br>
3. Current heuristic is to omit the placeholder on all but the first skeleton (there may be n skeletons)<br>
4. String join skeletons<br>
5. Replace duplicate whitespace<br>
<br>
This has similar issues as the previous “prefix” example - collapsing duplicate whitespace is required.<br>
It also has the heuristic of determining when to use the plural form for a sub-unit or the singular form.<br>
<br>
My implementation produces: "3 light years⋅furlongs”<br>
<br>
It uses the same plural form for all sub units. Its not “correct” English and its just as likely to be the wrong strategy for most locales (this is a guess).<br>
<br>
Many thanks for any help or suggestions,<br>
<br>
—Kip<br>
<br>
PS: In case anyone get this far, the implementation is in the Elixir language at <a href="https://github.com/elixir-cldr/cldr_units" rel="noreferrer" target="_blank">https://github.com/elixir-cldr/cldr_units</a><br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
CLDR-Users mailing list<br>
<a href="mailto:CLDR-Users@corp.unicode.org" target="_blank">CLDR-Users@corp.unicode.org</a><br>
<a href="https://corp.unicode.org/mailman/listinfo/cldr-users" rel="noreferrer" target="_blank">https://corp.unicode.org/mailman/listinfo/cldr-users</a><br>
</blockquote></div>