Closed timwright12 closed 1 month ago
Translation string contain "interpolated {{mustache}} variables"
so pedantically they're a form of code. Adding a variable to an existing string is not backwards compatible (removing one is). Any thought on what (if any) automated or manual checks should be done? Also open to punting on this question as it might not be a problem in practice.
I think we can do a form of contract testing between the app and the API to account for this. Either contract or building out the the existing e2e could work. Something to test.
I think this needs to be an Epic with split BE/FE changes associated. Reading this it's hard to discern order of ticket delivery and what types of integrations we'll need to consider. @timwright12 can we chat about this one and what our next steps should be? Seems like maybe Kris is already doing something here?
we'll need to sync with @StacyB2023 and @ajsarkar28 to line up this work
We were planning to use this ticket for the initial investigation into how exactly we would want to implement something like this. Assigned it to Kris because he'll be the BE SME for this feature. If we want to make a separate ticket for that let me know. We'll likely have time for it in the next sprint or two. @timwright12
@timwright12 since we have a full epic that we are tracking for this CMS/translation file migration work I think we can close this ticket?
@jperk51 yeah I'm good with that, close when ready
Description
As a content manager I want to be able to quickly release content into the app without having to wait for a full release cycle. I also want to be able to stage and review content prior to release.
Content for the VA Health and Benefits app currently functions off a large translation file containing ~1400 individual strings that are consumed by the app in various places. This content file is updated via pull request, shipped with app updates that happen (on average) every two weeks. With our CMS initiative our goal is to take a step in a direction to make this content updating process easier and faster.
Our initial intention is to test the hypothesis that we can effectively move the translation file from being housed inside the application to having it primarily live with the API to reduce the time to update from 2 weeks to 1 day without overtaxing local development, testing, and release processes. If possible, moving this file should be an initial step into consuming content from an external source (CMS) - the actual source being TBD.
View the original cms proposal document
Acceptance Criteria
- [ ] A proof of concept is created for the app to remotely manage content - [ ] Testing considerations have been documented - [ ] Local development considerations have been documented - [ ] Release update considerations have been documented ## Notes & Open Questions - Will this make translations easier or harder? - What do we do with screenreader pronunciations? - Will moving strings to the BE will make isolating their use more complicated? - How would the CMS and design system work together (or do they even need to)? - What formatting & spacing stuff is easier with a CMS? What's more difficult? ## Ticket Checklist - [X] Acceptance criteria defined - [X] Labels added (front-end, back-end, feature) - [ ] Linked to an Epic