You and Amy are going to run into a merge conflict here... I left this comment on Amy's pr too: Not blocking, but I personally prefer when we wait to pull in localized strings until they're actually translated; it's easier to check if they're translated or not when you're looking at a diff than if we're trying to confirm that every localized string that's visible to users during release time has been translated. So I'm okay with merging this as it is, but then we need to make sure we thoroughly check strings when we cut our next release build.

@ifosli How about we just add make strings to our deploy process? Should be an easy change in Circle CI. So long as nobody is pushing breaking changes to strings, it should be safe.

You and Amy are going to run into a merge conflict here... I left this comment on Amy's pr too: Not blocking, but I personally prefer when we wait to pull in localized strings until they're actually translated; it's easier to check if they're translated or not when you're looking at a diff than if we're trying to confirm that every localized string that's visible to users during release time has been translated. So I'm okay with merging this as it is, but then we need to make sure we thoroughly check strings when we cut our next release build.

@ifosli How about we just add make strings to our deploy process? Should be an easy change in Circle CI. So long as nobody is pushing breaking changes to strings, it should be safe.

@amy-at-kickstarter The challenge here is around test snapshots. They can fail when existing strings are updated. I see two possible approaches:

1. Integrate make strings into the CircleCI pipeline (as Amy suggested). If a build fails due to snapshot mismatches, a developer should jump in and update the affected snapshots.

2. Ensure that anyone (or the devs who pushed strings with incomplete translations) updates both the strings and the corresponding snapshots before the release cut (as Ingerid mentioned).