We currently lose information when we process the survey tool data, because we don't retain the information that the winning value is ↑↑↑ (soft bailey value). It also means that the server tooling (where the data has ↑↑↑) is processing different data than when it is brought into XML.
Here is the plan:
Add a CLDRModify option that updates all of the cldr data from the last vxml using the following scheme:
where vxml has ↑↑↑ and trunk is missing OR trunk = inherited, set trunk to ↑↑↑.
2. Process trunk to add the ↑↑↑ values. From then on, we maintain the ↑↑↑ values; when we generate the vxml data and bring it into trunk, iit will always have the ↑↑↑
3. Run the unittests and console checks, and fix tests as needed. (May be none, since servers use ↑↑↑.
4. Upload to Smoke test.
5. Write tool to generate production data. (This can be done after data submission.)
The production data can't have ↑↑↑ in it.
2. Add BRS step to generate production data, either have into a separate repository or treat like current JSON data.
3. Add options to the tool to do more thorough data reduction (dropping comprehensive (perhaps with certain exceptions)), dropping all items equal to their bailey values.
NOTE: Size in trunk increases a bit, but is manageable:
trunk/common/main: 48,308,774 bytes
vxml/common/main: 54,601,288 bytes (+6,292,514)
trunk/common/annotations: 22,099,286 bytes
vxml/common/annotations: 23,710,765 bytes (+1,611,479)
Total common: 178,476,827 bytes (+7,903,993 = +4.4%)