Update #130-2021-01-11.md

meetings/task-force/#130-2021-01-11.md

@@ -2,16 +2,16 @@
 Executive summary
 
 Participants:
-RCA: Romulo Cintra
-NIC: Nicolas Bouvrette - Expedia
-EAO: Eemeli Aro - OpenJSF
-DLM: Daniel Minor - Mozilla
-STA: Staś Małolepszy - Google
-ZBI: Zibi Braniecki - Mozilla
-DAF: David Filip - Huawei, OASIS XLIFF TC
-ECH: Elango Cheran - Google
-GWR: George Rhoten - Apple
-MIH: Mihai Nita
+- RCA: Romulo Cintra
+- NIC: Nicolas Bouvrette - Expedia
+- EAO: Eemeli Aro - OpenJSF
+- DLM: Daniel Minor - Mozilla
+- STA: Staś Małolepszy - Google
+- ZBI: Zibi Braniecki - Mozilla
+- DAF: David Filip - Huawei, OASIS XLIFF TC
+- ECH: Elango Cheran - Google
+- GWR: George Rhoten - Apple
+- MIH: Mihai Nita
 
 
 There is a general consensus around supporting dynamic references. There are some valid use cases to support, we probably can't prevent people from working around dynamic references, and by supporting them we “gain back” some control (conformance levels, lint, etc.). This can simplify messages that could otherwise have thousands of related static messages, but it brings along the risk of extra complexity and indirection. There are concerns about testing & validation -- ex: what happens at word boundaries, agreement between selector name, context completeness checking. Conformance levels with regards to this feature depend on the capability to switch off dynamic- and static message referencing. 
@@ -20,7 +20,8 @@ We agree to pause meetings of this particular task force for issue #130 until we
 
 
 
-Approval Stamps for Executive Summary
+> Approval Stamps for Executive Summary
+
 ECH
 RCA
 STA
@@ -29,7 +30,7 @@ DAF
 NIC
 
 
-Minutes
+## Minutes
 
 ZBI: Summary of dynamic selectors. Previously, we wanted to provide a design for developers to communicate to translators. Challenges at Mozilla happen at build time, developers don't know what messages they want to reference from another -- it is a runtime decision. Workarounds are messy, proposal is dynamic references -- have references to another message within a message that are only resolved at runtime. Avoids previous errors from workarounds of string concatenation and different fallback (locale?) of 2 different message patterns.