cc @CyrilleB79 @seanbudd, I would love to hear your thoughts on the situation I mentioned in the "Known issues with pull request" section.
I am leaning towards implementing logic that parses the translated strings, which would offer greater flexibility and maximize reuse for localization. However, I was wondering if you think there might be a better or more idiomatic approach to handle this?

Thanks for your help!

If I'm correct, these messages are reported when using selection / deselection commands. Thus it is more important to know what has been selected / deselected first and then to append "selected" or "deselected" as already done in most languages.

Thus, you should try to contact all translators who have not "%s" at the beginning of the translated string and discuss with them if they agree to put "selected" / "deselected" at the end, explaining why (information most important first). They may accept or decline this proposal, if possible with an explanation.

Then there are two possibilities:

• either they all accept to switch their strings and thus you have nothing more to do
• or there is a situation with their languages making such switch unsuitable. In this case, you can implement translatable string parsing, as you suggested, and as I have already done for "cap" indicator in _getSpellingCharAddCapNotification function in speech.speech.py.

To be more specific, I have scanned the existing translations. It appears that Vietnamese (vi) is the only language currently with an inconsistent format regarding the placement of %s. Here is a detailed summary:

• %s at the BEGINNING (50 languages): Most languages follow this pattern.

• %s at the END (1 language):

• vi: đã chọn %s

• Untranslated or Empty String (13 languages): af_ZA, am, bn, id, is, kn, lt, nn_NO, pa, so, sq, th, ur.

I am not sure if any translators responsible for the Vietnamese localization will see this PR. It would be great if someone could help CC them so we can discuss if they would be open to moving %s to the beginning for consistency.

Furthermore, I am concerned that the 13 untranslated languages might also require placing %s at the end in the future, similar to Vietnamese. I would appreciate guidance from the NV Access team on this. I understand you are busy, but your perspective on whether we should proactively handle this via code logic or stick to the translation-first approach would be invaluable for me to move this PR forward.
cc @SaschaCowley @gerald-hartig

I am not sure if any translators responsible for the Vietnamese localization will see this PR. It would be great if someone could help CC them so we can discuss if they would be open to moving %s to the beginning for consistency.

Most translators do not follow PRs or issues on NVDA's GitHub repo.
The best place to reach them is the NVDA translations mailing list, and the Vietnamese translator has just written there so he/she will read you if you write there.
If you are not subscribed to this list and do not plan to, I may write there for you. Let me know.

Furthermore, I am concerned that the 13 untranslated languages might also require placing %s at the end in the future, similar to Vietnamese. I would appreciate guidance from the NV Access team on this. I understand you are busy, but your perspective on whether we should proactively handle this via code logic or stick to the translation-first approach would be invaluable for me to move this PR forward.

Even if we need to ask confirmation to the Vietnamese translator for correctness, I am almost sure that the order can be with the placeholder (%s) at the beginning in all languages. At worst, the grammar may be incorrect in some cases but this is acceptable in some screenreader messages when one want to promote efficiency, reporting the most useful information first, against grammatical correctness.

Thus, I think we do not need to bother with untranslated languages. This string is quite old so translators have had time to translate it if they wish. And if in the future your new code causes a problem when translating a specific language, we may change the design again, based on this real-life problem.

This is a fascinating linguistics problem. Doing a bit of research, Vietnamese is only the canary in the coal-mine for this. Other verb-subject-object languages that may be similarly affected include:

• Thai
• Celtic (Irish, Welsh, Scottish Gaelic)
• Polynesian (Maori, Hawaiian, Samoan)
• Semitic (Arabic, Hebrew)

Forcing the "A selected" structure in Vietnamese results in a sentence closer in meaning to "A has selected [something]". That being said, Vietnamese allows slightly longer passive phrasings that would allow the "A selected" structure. That language has the capability to make the "A selected" structure work in a grammatically correct way. Given there are other VSO languages, we may also want to check with translators from those community how they've handled it.

Thanks @CyrilleB79 and @gerald-hartig

I've posted a new topic in Translation Group:
https://groups.io/g/nvda-translations/topic/seeking_feedback_on_capital/117574747

Hi @seanbudd and @SaschaCowley

Thanks for the suggestions! I've updated the implementation:

1. Refactored _getSelectionMessageSpeech to accept SpeechSequence and use partition("%s"). This handles localization order correctly for all languages without needing new strings.
2. Removed the redundant single-char helper functions and reused existing logic.
3. Updated type hints to use | None as requested.
   Ready for review!

FYI, there is an answer from the Vietnamese translator on the translators mailing list:

Hi all,
I’m writing this reply as the official Vietnamese language translator for NVDA.
Regarding the placeholder placement in the "selected/unselected" string: I have conducted a brief informal survey with Vietnamese users, and the general consensus is that this interpretation issue is not highly critical. Both structures, the current "đã chọn %s (selected %s)" and the proposed "%s đã chọn (%s selected)," are understandable and acceptable in the context of Vietnamese grammar and usage for a screen reader announcement.
Given that the proposed change, "%s đã chọn," would simplify the implementation and improve consistency with most other languages, please feel free to proceed with the change as you see fit. We are committed to localization quality, but in this specific case, technical convenience is a reasonable trade-off.
Anh Đức

Given your last changes, this may not be needed anymore though.

Thanks @CyrilleB79,
I think this information might not be decisive for the current direction anymore, but I am very glad to hear the feedback from the Vietnamese localization maintainer as well as the information provided by @gerald-hartig, and I appreciate you coordinating this.

I've reverted the generator approach and returned to the list-based implementation with localization fixes.

Hello @SaschaCowley
The test failure was caused by processText() stripping leading whitespace from " selected" when it was a separate list item in the speech sequence. The fix merges prefix/suffix directly with adjacent string items to preserve spacing. Performance impact is negligible.
Note: The VSCode test failure in CI is unrelated to this change.
Please review.