Discussion: imperial/metric static strings

[marc-medley]

@slavick Below are some observations on how the imperial/metric static strings are handled.

Currently Android and iOS handle the imperial/metric static strings for the detailed description differently.

Android separates the number value from rest of the string in XML and then recombines the number to the string in the code at run time.

The translation TSV spreadsheets have a full imperial string and separate a full metric string. Thus, for the translator, the string reads as is displayed and does not need to deal with any %s separations and formatting as exits in the XML file.

For iOS, the imperial and metric translation strings from the spreadsheets are displayed without any additional processing.

If dynamic valued internationalized strings were needed, then iOS would use an object which supports value + units + description; and the spreadsheets would need to add value and units columns. However, since the values are static the spreadsheet string is used directly for iOS.

The XmlFromTsvProcessor.swift code has a method measureDescriptionSplit(…) which splits the 2 translator strings (imperial and metric) into the 3 strings (description, imperialMeasure, and metricMeasure) as used by Android XML. The Hebrew translator being (right-to-left) highlighted that this particular method is left-to-right centric. For example, the multi character values such as 1/2 appeared to have issues which were subsequently avoided by using the single character ½.

I'm wondering if the overall process could be more robust and simplified if the Android app also used the static imperial and metric strings directly.

It would be a minor adaption to disable the measureDescriptionSplit(…) and generate the Android localized strings.xml files with the two separate imperial|metric strings instead of the 3 description|imperialMeasure|metricMeasure strings.

Your thoughts?

[marc-medley]

@slavick Updated XML files (1st pass) are provided with PR #204 for review.

In the string.xml files, the only content structure change should be the string-array food_info_serving_sizes_* elements. Other string.xml changes should only be formatting into a common order to support comparison via a common text compare tools.

Existing release food_info_serving_sizes_* content structure:

<string-array name="food_info_serving_sizes_other_fruits">
    <item>%s1 medium-sized fruit</item>
    <item>1%s cut-up fruit</item>
    <item>%s dried fruit</item>
</string-array>
<string-array name="food_info_serving_sizes_other_fruits_imperial">
    <item />
    <item> cup</item>
    <item>¼ cup</item>
</string-array>
<string-array name="food_info_serving_sizes_other_fruits_metric">
    <item />
    <item>20 g</item>
    <item>40 g</item>
</string-array>

Proposed food_info_serving_sizes_* content structure is shown below. Fewer elements. Easer to read. One-to-one correspondence to what the translator sees in a spreadsheet row.

<string-array name="food_info_serving_sizes_other_fruits_imperial">
    <item>1 medium-sized fruit</item>
    <item>1 cup cut-up fruit</item>
    <item>¼ cup dried fruit</item>
</string-array>
<string-array name="food_info_serving_sizes_other_fruits_metric">
    <item>1 medium-sized fruit</item>
    <item>120 g cut-up fruit</item>
    <item>40 g dried fruit</item>
</string-array>

[slavick]

I like the suggestion and have pushed the code for implementing the change: 830eff3