yes, PA for Excel follows the system culture.

as before in the old multi-file version, expectation is that you can adjust the resources on profile to custom cross map culture to a relevant language pack.

the doc topic is slightly stale (as the disk format was adjusted in the single file version), but still generally applies. (which is, 'put the file in the place to get the outcome you want')

https://www.ibm.com/docs/en/planning-analytics/2.0.0?topic=rcoc-run-cognos-office-components-in-english-in-localized-microsoft-windows-environment

so, in your specific example, you should be able to take the relevant 'zh' language resource in <userprofile>\AppData\<profile layer>\Cognos\Office Connection\LanguageResources , and replace them with renamed copies of the 'en' files. be sure to do both the cor and coi messages. note the steps may need to be repeated whenever the software is updated with new strings, though we have some protections in place to reduce this.

long term, we may introduce a more explicit locale override setting as we look to compact the addin footprint further (and want to remove such labor), but for now strings are being managed in the longstanding flow and some customers have an existing dependency there (as you can see from the topic). That's not something we've signaled a change timeline for, but I would like to exit.

yes, PA for Excel follows the system culture.

as before in the old multi-file version, expectation is that you can adjust the resources on profile to custom cross map culture to a relevant language pack.

the doc topic is slightly stale (as the disk format was adjusted in the single file version), but still generally applies. (which is, 'put the file in the place to get the outcome you want')

https://www.ibm.com/docs/en/planning-analytics/2.0.0?topic=rcoc-run-cognos-office-components-in-english-in-localized-microsoft-windows-environment

so, in your specific example, you should be able to take the relevant 'zh' language resource in <userprofile>\AppData\<profile layer>\Cognos\Office Connection\LanguageResources , and replace them with renamed copies of the 'en' files. be sure to do both the cor and coi messages. note the steps may need to be repeated whenever the software is updated with new strings, though we have some protections in place to reduce this.

long term, we may introduce a more explicit locale override setting as we look to compact the addin footprint further (and want to remove such labor), but for now strings are being managed in the longstanding flow and some customers have an existing dependency there (as you can see from the topic). That's not something we've signaled a change timeline for, but I would like to exit.