Add GitHub push action enforcing Prettier style (#451)

* Add GitHub push action enforcing Prettier style

Co-authored-by: Steven R. Loomis <[email protected]>

* style: Apply Prettier

---------

Co-authored-by: Steven R. Loomis <[email protected]>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,10 +1,9 @@
 ---
 name: Feature request
 about: Suggest an idea or feature for Message Format
-title: ''
-labels: ''
-assignees: ''
-
+title: ""
+labels: ""
+assignees: ""
 ---
 
 **Is your feature request related to a problem? Please describe.**

.github/workflows/prettier.yaml

@@ -0,0 +1,30 @@
+name: Apply Prettier style
+
+on:
+  push:
+    paths:
+      - "**.md"
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  prettier:
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v3
+      - uses: actions/setup-node@v3
+        with:
+          node-version: "20.x"
+      - run: npm install --no-save prettier@3
+      - run: npx prettier --write .
+      - name: git config
+        run: |
+          git config user.name "github-actions[bot]"
+          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+      - run: git add .
+      - name: git commit & push any changes
+        run: |
+          git diff-index --quiet HEAD || (git commit -m "style: Apply Prettier" && git push)

.gitignore

@@ -1 +1,2 @@
-.DS_Store
+.DS_Store
+node_modules/

CONTRIBUTING.md

@@ -10,6 +10,7 @@ the information on the Contributor License Agreement below. In addition, you sho
 2. Watch this repository (use the "Watch" button in the upper right corner)
 
 <!-- boilerplate follows - do not edit -->
+
 ## Contributor License Agreement
 
 In order to contribute to this project, the Unicode Consortium must have on file a Contributor License Agreement (CLA) covering your contributions, either an individual or a corporate CLA. Pull Requests will not be merged until the correct CLA is signed. Which version needs to be signed depends on who owns the contribution being made: you as the individual making the contribution or your employer. _It is your responsibility to determine whether your contribution is owned by your employer._ Please review [The Unicode Consortium Intellectual Property, Licensing, and Technical Contribution Policies][policies] for further guidance on which CLA to sign, as well as other information and guidelines regarding the Consortium’s licensing and technical contribution policies and procedures.
@@ -20,7 +21,6 @@ In order to contribute to this project, the Unicode Consortium must have on file
 
 Unless otherwise noted in the LICENSE file, this project is released under the free and open-source [Unicode License][unicode-license], also known as Unicode, Inc. License Agreement - Data Files and Software.
 
-
 [policies]: https://www.unicode.org/policies/licensing_policy.html
 [unicode-corporate-clas]: https://www.unicode.org/policies/corporate-cla-list/
 [signing]: https://www.unicode.org/policies/licensing_policy.html#signing

README.md

@@ -56,15 +56,15 @@ See more examples and the formal definition of the grammar in [spec/syntax.md](.
 
 ### Implementations
 
-* Java: [`com.ibm.icu.message2`](https://unicode-org.github.io/icu-docs/apidoc/dev/icu4j/index.html?com/ibm/icu/message2/package-summary.html), part of ICU 72 released in October 2022, is a _tech preview_ implementation of the MessageFormat 2 syntax, together with a formatting API. See the [ICU User Guide](https://unicode-org.github.io/icu/userguide/format_parse/messages/mf2.html) for examples and a quickstart guide.
-* JavaScript: [`messageformat`](https://github.com/messageformat/messageformat/tree/master/packages/mf2-messageformat) 4.0 implements the MessageFormat 2 syntax, together with a polyfill of the runtime API proposed for ECMA-402.
+- Java: [`com.ibm.icu.message2`](https://unicode-org.github.io/icu-docs/apidoc/dev/icu4j/index.html?com/ibm/icu/message2/package-summary.html), part of ICU 72 released in October 2022, is a _tech preview_ implementation of the MessageFormat 2 syntax, together with a formatting API. See the [ICU User Guide](https://unicode-org.github.io/icu/userguide/format_parse/messages/mf2.html) for examples and a quickstart guide.
+- JavaScript: [`messageformat`](https://github.com/messageformat/messageformat/tree/master/packages/mf2-messageformat) 4.0 implements the MessageFormat 2 syntax, together with a polyfill of the runtime API proposed for ECMA-402.
 
 ## Sharing Feedback
 
 We invite feedback about the current syntax draft, as well as the real-life use-cases, requirements, tooling, runtime APIs, localization workflows, and other topics.
 
-* General questions and thoughts → [post a discussion thread](https://github.com/unicode-org/message-format-wg/discussions).
-* Actionable feedback (bugs, feature requests) → [file a new issue](https://github.com/unicode-org/message-format-wg/issues).
+- General questions and thoughts → [post a discussion thread](https://github.com/unicode-org/message-format-wg/discussions).
+- Actionable feedback (bugs, feature requests) → [file a new issue](https://github.com/unicode-org/message-format-wg/issues).
 
 ## Participation
 

delegates.md

@@ -1,11 +1,10 @@
-MessageFormat Working Group Delegates
-=====================================
+# MessageFormat Working Group Delegates
 
 MessageFormat Working Group uses the standard TC39 note-taking procedures, including unique abbreviations for all delegates.
 
 ## Acronym Conventions
 
-With the exception of certain grandfathered delegates, all delegates should have three-letter abbreviations.  The following scheme is recommended:
+With the exception of certain grandfathered delegates, all delegates should have three-letter abbreviations. The following scheme is recommended:
 
 - Suggestion 1: First letter of given name, First letter of surname, Last letter of surname.
   - Example: Gordon Moore → GME
@@ -27,7 +26,7 @@ Please include your primary affiliation (e.g., the company you represent or wher
 - Eemeli Aro - OpenJSF & Vincit (EAO)
 - Elango Cheran - Google (ECH)
 - George Rhoten - Apple (GWR)
-- Jan Mühlemann  - Locize (JMU)
+- Jan Mühlemann - Locize (JMU)
 - Janne Tynkkynen - PayPal (JMT)
 - Jeff Genovy - Microsoft (JMG)
 - John Watson - Facebook (JRW)

docs/chair-group.md

@@ -13,10 +13,9 @@ The Chair Group is a representative body of the Message Format WG that collectiv
 - Manage and accept WG applications.
 
 - Manage and organize all WG communication channels, email, mail group, boards and Github repositories.
-
 - Prioritize, label and organize the tasks of the WG.
 
-- Use the possibility of e-mail or  synchronization meetings to discuss issues or organize WG work.
+- Use the possibility of e-mail or synchronization meetings to discuss issues or organize WG work.
 
 - Create and update events and agenda.
 
@@ -25,7 +24,6 @@ The Chair Group is a representative body of the Message Format WG that collectiv
 - Take care of the minutes of the meetings, including recording of all decisions. The minutes and presentations given in WG should be available in the WG Drive.
 
 - Prepare technical drafts and documentation.
-
 - Formulate concrete questions that the WG can answer in their monthly meetings.
 
 #### Participate

docs/consensus_decisions.md

@@ -19,7 +19,7 @@ For more details on the process that lead to these decisions, please refer to th
 - **Consensus 5 & 6:**
   The solution for [issue #127](https://github.com/unicode-org/message-format-wg/issues/127).
   Codified in [issue #137](https://github.com/unicode-org/message-format-wg/issues/137) during the [January 2021 meeting](https://github.com/unicode-org/message-format-wg/issues/146) of the working group.
-  Discussed and accepted at the  [February 2021 meeting](https://github.com/unicode-org/message-format-wg/blob/HEAD/meetings/2021/notes-2021-02-15.md) of the working group.
+  Discussed and accepted at the [February 2021 meeting](https://github.com/unicode-org/message-format-wg/blob/HEAD/meetings/2021/notes-2021-02-15.md) of the working group.
 - **Consensus 7:**
   Discussed at the [22 September 2021 meeting](https://github.com/unicode-org/message-format-wg/issues/196) of the working group.
 

docs/contributing-to-agenda.md

@@ -1,17 +1,17 @@
 ## Contributing to Meetings
 
 ### Prepare Content
- - Well ahead of the MFWG plenary meeting, produce and publish documentation about your proposal/idea, slides, design document, Github issue or any other relevant material, to be shared beforehand and presented during the meeting.
+
+- Well ahead of the MFWG plenary meeting, produce and publish documentation about your proposal/idea, slides, design document, Github issue or any other relevant material, to be shared beforehand and presented during the meeting.
 
 ### Getting on the agenda
+
 To propose a presentation/ time slot in MFWG plenary meetings:
 
 - If there is not already an issue describing your topic, create one.
-    > Include all relevant information about the topic including necessary documentation.
-    
+  > Include all relevant information about the topic including necessary documentation.
 - Add the label `Agenda+` to the issue.
 
 - Write to the [group email](https://groups.google.com/a/chromium.org/forum/#!forum/message-format-wg) asking the chair to add your item to the agenda _at least_ 48 hours in advance of the next call. More time is better. Note that the chair may choose to defer your item until a later meeting or to "future". Be sure to indicate any time restrictions you have.
-
-- Watch for the chair to update the [official agenda](https://github.com/unicode-org/message-format-wg/blob/main/meetings/agenda.md). 
-    - Notes for each meeting can be found by date under [this link](https://github.com/unicode-org/message-format-wg/tree/main/meetings)
+- Watch for the chair to update the [official agenda](https://github.com/unicode-org/message-format-wg/blob/main/meetings/agenda.md).
+  - Notes for each meeting can be found by date under [this link](https://github.com/unicode-org/message-format-wg/tree/main/meetings)

docs/decision-process.md

@@ -1,22 +1,23 @@
 # Decision making process
 
-
 ## Definitions
-1. *Consensus* is defined as lack of sustained opposition.
-2. *Good standing* is a characteristic of group members who fullfill their implicit and explicit obligations and hence are allowed to excercise all of their rights within the group without restriction.
-3. *Proscribe* (*proscribe*, *proscribed*, *proscription*) is a taxative enumeration of group members who are temporarily excluded from exercising their rights within the group.
-4. *Normative keywords* as defined in [BCP 14](https://tools.ietf.org/html/bcp14)
+
+1. _Consensus_ is defined as lack of sustained opposition.
+2. _Good standing_ is a characteristic of group members who fullfill their implicit and explicit obligations and hence are allowed to excercise all of their rights within the group without restriction.
+3. _Proscribe_ (_proscribe_, _proscribed_, _proscription_) is a taxative enumeration of group members who are temporarily excluded from exercising their rights within the group.
+4. _Normative keywords_ as defined in [BCP 14](https://tools.ietf.org/html/bcp14)
 
 ## Rules
+
 1. Any current group member is deemed to be in good standing unless proscribed.
 2. Any group member in good standing MAY make a proposal to the group via
-    - raising an issue,
-    - PR (against the repo or wiki), or
-    - orally in a monthly group meeting.
+   - raising an issue,
+   - PR (against the repo or wiki), or
+   - orally in a monthly group meeting.
 3. Approval or rejection of proposed solutions and decisions SHOULD be driven by consensus.
 4. Consensus MAY be reached as part of the PR or issue resolution process.
 5. The monthly group meeting has the ultimate decision making authority.
-    - Chair Group or Chair don't have a decision making authority, see [chair-group.md](chair-group.md) and [chair-group-members.md](chair-group-members.md).
+   - Chair Group or Chair don't have a decision making authority, see [chair-group.md](chair-group.md) and [chair-group-members.md](chair-group-members.md).
 6. In case consensus cannot be found over multiple iterations of arguments and counter arguments, a monthly group meeting MAY reach consensus to mandate the Chair Group to organize a ballot among all group members in good standing. The ballot wording, options, and success criteria SHOULD be explicitely defined in a monthly meeting. The Chair Group only administers and implements the ballot and its results.
 7. Proscription procedure is TBD by monthly meeting consensus if and when needed.