Closed marc-medley closed 2 years ago
@slavick Updated XML files (1st pass) are provided with PR https://github.com/nutritionfactsorg/daily-dozen-android/pull/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>
I like the suggestion and have pushed the code for implementing the change: https://github.com/nutritionfactsorg/daily-dozen-android/commit/830eff3dccaed8b9a250b3346e90cbfeeea23014
@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 addvalue
andunits
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 as1/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 localizedstrings.xml
files with the two separate imperial|metric strings instead of the 3 description|imperialMeasure|metricMeasure strings.Your thoughts?