• FAIL: Translation comments check. Translation comments missing or unexpectedly included. See build log for more information.
• PASS: License check.
• PASS: Unit tests.
• PASS: Lint check.
• PASS: System tests (tags: installer NVDA).
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/yj03ojc4b6wubepw/artifacts/output/l10nUtil.exe nvda_snapshot_pr17324-34415,c51766cc.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 1.5,
  INSTALL_END 1.0,
  BUILD_START 0.0,
  BUILD_END 26.5,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.4,
  TEST_START 0.0,
  TEST_END 18.9,
  FINISH_END 0.1

See test results for failed build of commit c51766ccdb

I really don't think this should be in the title bar (it isn't visually, right?). Perhaps it could be assigned to a separate script?

Hi Noelia.

Thanks for addressing this issue. It will be very useful.

This approach with the status bar is not the best design choice IMO. Indeed, the view ribbon allow you to select outline or draft mode but there are no corresponding buttons, at least by default, in the status bar. Also, are we sure that the status bar cannot contain any other pressed button?

As suggested in #15088 (comment), I'd rather opt for the Word Object Model approach. Using the macro recorder and playing with the buttons in the view ribbon, you can find the relevant objects/properties/methods; then you can complete your information by googling the corresponding MSDN page (e.g. "VBA word view").

Also, rather than duplicating the NVDA+T script, I'd keep one single script. As for the processing done to read the status bar text (see api.getStatusBar), I'd create a function allowing to get the title in the general case or delegating this task to Word's appModule when in Word. The advantages of a single script are that:

• the processing done with the text (e.g. spelll if two presses, etc.) remains factorized; so if we change what to do on triple press in the future, we will have to change it only at one place.
• if someone change the script's gesture NVDA+t to NVDA+shift+t, it will be changed in all context at once. Keeping two separated scripts, people may not understand easily that they have to change the gesture in Word and out of Word.

To be complete, the drawback of having one single script is that you cannot use a separate description in Word.

Re @codeofdusk feedback:
It's true that the title bar does not show this information. Though, a dedicated script is not a better solution IMO.
If we want this feature to be useful, the information should:

• either be reported along with a frequently used script (current implementation)
• or reported upon a specific event, e.g. when the application gets the focus

What about including it in the name property of the document's NVDAObject?

What about including it in the name property of the document's NVDAObject?

Yes, that seems an interesting option. It would be reported when the document gets focused or when calling NVDA+tab.
It's worth noting that the name seems to be "Document Microsoft Word". We may replace it by "Document {viewMode}". No need to keep the "Microsoft Word" information; I should already know that I am in Word.

For me, adding this to the document name is a good option.
Though, according to #15088, in JAWS this seems to be reported in the title.
I think that this should be reported on demand when the user wants, not just when an event is fired.
Anyway, note that if we report this in the document name, when the ribbon is active it won't be availab.e.
My first approach was to include the script just in the document class, and then I moved it to the app module so that it's available from the ribbon too.
I'll wait for more feedback, or I can mark this as ready for review to see opinions from NV Access too.

Exploring Microsoft Word, pragmatically, I think that including this in the title may be more useful. For example, if we want to change the layout from the ribbon, we may press NVDA+tab to remember the focused button, and we can have the current layout in the title.

I'll mark this as ready for review, and feedback is welcome.

@nvdaes regarding the second point in #17324 (comment), namely making NVDA+t a single script, could you share your opinion?

I have thought about a single script, but finally I decided to use a separate script. In this way:

• The global commands script is more simple. Other app modules, in the future, may implement a report title command for different applications, and having this in a single script is les maintainable imo.
• If someone prefers to use the standard script, without reading the document layout, this can be achieved by removing NVDA+t gesture for the Word command.
• If someone wants to have different gestures for the global commands title script and the script for Word, it can be done too.

in JAWS this seems to be reported in the title.

@michaelDCurran and @jcsteh hold that NVDA and JAWS are very different products and take very different philosophical approaches. If a user asks for the window title, they should get the window title.

I wholeheartedly agree with @codeofdusk with regard to his concern about using the title for this.
I like the idea to use the word document object instead, tough may be the description is more suitable than the name of the object.

@CyrilleB79 wrote:

This approach with the status bar is not the best design choice IMO. Indeed, the view ribbon allow you to select outline or draft mode but there are no corresponding buttons, at least by default, in the status bar. Also, are we sure that the status bar cannot contain any other pressed button?

As suggested in #15088 (comment), I'd rather opt for the Word Object Model approach. Using the macro recorder and playing with the buttons in the view ribbon, you can find the relevant objects/properties/methods; then you can complete your information by googling the corresponding MSDN page (e.g. "VBA word view").

I also tend to agree here. @nvdaes could you please address this as well?

Hi reviewers, thanks for your feedback. Now we use WinwordWindowObject.view.Type to set the corresponding display string to the description. Comments are appreciated.

@codeofdusk , I've handled cases where WinwordWindowObject is not available. In this case the description should be empty.

@codeofdusk wrote:

If Word adds a description or help text at any point, it'll be thrown away after this PR. Is this desirable?

Probably no. If you have precise suggestions, feel free to provide them.
Thanks.

Thanks @SaschaCowley . Probably your suggestion is the best one, i.e., prepending the document view instead of appending it to the possible available description, so that this info is always read after the document name. I've committed your suggestion.
Thanks also to all reviewers.

Thanks @codeofdusk

@nvdaes With current Alpha, the word document object has a description of Print layout None here.

Thanks so much @LeonarddeR .
I opened issue #17338
When this is triaged I'll fix it.
I opened issue #17338

@nvdaes no need to wait for NV Access to triage this before submitting a fix. You can triage it yourself though if you like.