English_US v6 Files Update

[drrandall-dev]

The app and store files for the v6 update of the daily dozen app are attached.

English_US_en.app.v06.txt
English_US_en.store.v06.txt

[marc-medley]

@drrandall-dev The English_US provided app and store .txt files migrated OK to .tsv files in Languages/English_US/tsv/v06. Thanks.

• English_US_en.app.v06.20250304.delta_index.tsv shows 26 items which are strictly indexing updates.
• English_US_en.app.v06.20250304.delta_lang.tsv shows 35 items to be reviewed for quantity and/or text copy changes.

Other status updates will be provided here as the process continues.

[marc-medley]

@drrandall-dev Additional review found some anomalies in the English_US_en.app.v06.txt file:

1. Redundant Lychees. A redundant instance of Lychees exists at the key dozeFruitsOther.Variety.Text.28. Lychees is already in the app at position dozeFruitsOther.Variety.Text.13. Was there something else that was planned to have been added to the list?

2. Different Imperial/Metric Text. The imperial and metric description text is expected to be the same even though the units change between the different measurement systems. What wording is preferred in each case?

   • dozeWholeGrains.Serving.….0
     • "cooked whole grains, whole-wheat pasta, or corn kernels"
     • "hot cereal or cooked grains, pasta, or corn"
   • dozeWholeGrains.Serving.….1
     • "100% whole grain cold cereal"
     • "cold cereal"

A reply comment is sufficient… i.e. no need to edit and upload a changed .txt file.

Thanks.

[drrandall-dev]

1. The lychees requirement requested the addition of lychees video. I misunderstood the requirement added lychees. The lychees (13) is fine and it should get a link (https://nutritionfacts.org/video/lychee-fruit-and-hypoglycin-how-many-are-too-many/). The second lychees added (28) should be removed.
2. The imperial text (0, 1) is correct. The corresponding metric text should be updated to be the same as the imperial text.

Thank you!

[marc-medley]

@salitrov The version 6 changeset is ready for the translators to review and update. The Multi.app.v06.toreview.tsv and Multi.store.v06.toreview.tsv files contains all the translations currently in use for the mobile app and the store webpages.

• Languages/English_US/tsv/v06/Multi.app.v06.toreview.tsv
• Languages/English_US/tsv/v06/Multi.store.v06.toreview.tsv

The Multi combined language format avoids the past approach which used separate spreadsheets for each language.

The done column needs to be updated to y or yes for the rows completed. The done field is case-insentive so that other variations like Y or Yes would be ok too.

If there's a scenario where you'd like to use just the TSV portion for a specific language, that would be OK too. The intake processing can with a combination of the Multi…*.tsv file and individual language…*.tsv files.

All the language specific v06 changeset are in the corresponding Languages/…/tsv/v06 directories. The .change. filename segment is used indicate a file which has the subset of row that have changed … as shown for Spanish below.

Spanish_es

• Languages/Spanish/tsv/v06/Spanish_es.app.v06.change.tsv
• Languages/Spanish/tsv/v06/Spanish_es.store.v06.change.tsv

For example: @angelagvarela, @Lbouska, and @Hangur who have submitted language specific translations directly to the this repository in the past, can still do so.

[marc-medley]

As FYI, here are some additional notes on multi-language intake processing...

• The intake processing is set up to be based on a time ordered list of (1 or more) filenames.

• Only the "y/yes" part of a multi-language file is processed-in from any specific file. So, the yes/no is like an on/off switch for that part of that particular file.

• In the time order file list, newer files have precedence over older files. In other words, a yes row in a newer file will supersede (overwrite) the corresponding yes row of an older file. This approach helps find corrections (updates) automatically.

• Also, if one file has a y/yes for one language and other file has y/yes for another language, then the output becomes an aggregate merge of both the y/yes languages for the next processing stage.

• Both the multi-language file format and the existing single language file format can be included on the intake processing.