Known issues with pull request:

To reduce the diff and limit the API impact for add-ons, I did not rename ExcelCellInfo.formula nor add a formulaLocal member. Instead, I simply filled the existing structure member with the appropriate value.
Please let me know if you feel this is less readable and prefer I proceed otherwise.

I'm not sue about this one. EXCEL_CELLINFO isn't our structure, right?
It is very unlikely that add-ons are using NVDAHelper code directly, so I think it makes sense to use local everywhere.

@LeonarddeR wrote:

I'm not sue about this one. EXCEL_CELLINFO isn't our structure, right?

If I'm not wrong, it is, as of #9257,.

It is very unlikely that add-ons are using NVDAHelper code directly,

I was rather thinking of using the structure as already retrieved on the Python side.

so I think it makes sense to use local everywhere.

This is indeed what I did.
I filled the existing formula member with localized version instead of English version, without renaming nor adding an extra formulaLocal member - guessing typical use of this data is for presenting to the user rather than processing based on standardized English form.

Do you mean you'd prefer I rename the member? Or include both versions in the structure?

I'm not sue about this one. EXCEL_CELLINFO isn't our structure, right?

If I'm not wrong, it is, as of #9257,.

Yes, you're correct, I"m sorry.

I filled the existing formula member with localized version instead of English version, without renaming nor adding an extra formulaLocal member - guessing typical use of this data is for presenting to the user rather than processing based on standardized English form.

I think it all depended on whether the structure was our own or not. As it is ours, I think it is OK to leave this as is. Just forget my earlier comment ;)

To reduce the diff and limit the API impact for add-ons, I did not rename ExcelCellInfo.formula nor add a formulaLocal member. Instead, I simply filled the existing structure member with the appropriate value.
Please let me know if you feel this is less readable and prefer I proceed otherwise.

My only concern with this is if NVDA / other code (addons?) is looking for "known values" in the non-localized version of this. It seem unlikely if it is just the formula, but it would be good to spend a little time to see if that is possible.

To reduce the diff and limit the API impact for add-ons, I did not rename ExcelCellInfo.formula nor add a formulaLocal member. Instead, I simply filled the existing structure member with the appropriate value.
Please let me know if you feel this is less readable and prefer I proceed otherwise.

My only concern with this is if NVDA / other code (addons?) is looking for "known values" in the non-localized version of this. It seem unlikely if it is just the formula, but it would be good to spend a little time to see if that is possible.

Indeed only the formula is concerned by the proposed change.
And yes, any attempt on parsing/processing/identifying standardized English Excel function identifier is thus affected, which motivated my warning.
I'm not aware of any add-on that would be affected though, but you for sure have a wider view than I do in that matter.
As mentioned in #11329 (comment), my guess is that the formula is only ever used for presentation to the user.
Still, if you prefer ensure supporting current or future formula parsing, let me know and I'll add both versions in the structure - with a slight performance penalty.

EDIT: Regarding the possible customized processing of some specific spreadsheet as might be required by our customers here at Accessolutions, we could not foresee a case where the same code would need to apply in different locale, thus the localized version still meets our needs in that matter. Only speaking in our name, though.

I am fine with reusing the existing struct member for the localized formula. I cannot think of a situation where an appModule developer could fairly argue they wanted to match logic against a raw formula.

I wasn't able to work out a good way to explain this change as it might appear to an add-on developer. I didn't add anything to the changes for developers section for this. Suggestions / PR welcome!