Brandon Henry

@iwiznia @jayeshmangwani so the reason this was failing is because we for some reason have an [array for this specific](https://github.com/Expensify/App/blob/f1502291a14d4e15e04249b241109f146bdb512f/src/languages/en.ts#L447) translation phrase. Every other translation in this file is a...

@jayeshmangwani @iwiznia Alrighty, updated the function to handle that one off array translation. I also updated it so that we didn't have to alter phraseKey at all. Now, if you...

on it @jayeshmangwani ! I will have this updated soon, hopefully before my lunch

@iwiznia sounds good. i added a condition to check for it but i totally am aligned with removing the array. Then I can remove [this condition](https://github.com/Expensify/App/blob/35b8f1c803785d755d48e05eef7336ca00d3573e/src/libs/Localize/index.ts#L155)

Still working through this, sorry didn't have much time yesterday. Hoping to get that other array updated today

this is looking better now @iwiznia @jayeshmangwani - removed that array from the list and tested things out again. looks good - let me know your thoughts

i was testing with local changes (review prior pointed them out so i didn't commit this time). Probably better to write some unit tests to go with this @iwiznia

@iwiznia i took a look into the typing myself and it definitely gets pretty dang deep and nested. I think the main issue, is that everything in `en` is not...

To be clear, the types are deeply nested due to our use of [Flatten here](https://github.com/Expensify/App/blob/db9e01cc302df7f2b3dd53a99c1082404676aedb/src/languages/types.ts#L284). we should be able to do something like `type TranslationPaths = keyof EnglishTranslation;` and be...

I fixed things on my recent push Edit: I ended up changing what i went with an alternative route which looks to be working other than breaking the way we...