Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

appmodule for poedit #1811

Closed
nvaccessAuto opened this issue Sep 18, 2011 · 15 comments
Closed

appmodule for poedit #1811

nvaccessAuto opened this issue Sep 18, 2011 · 15 comments
Labels
component/i18n existing localisations or internationalisation enhancement
Milestone

Comments

@nvaccessAuto
Copy link

Reported by MHameed on 2011-09-18 20:46
Prep work for #1410 and #1524.
Translators can easely localize messages using poedit, but can currently not read comments, either inserted by other translators or automatically extracted from code.
The attached appmodule adds two shortcuts, control+shift+c for reading translation comments, and control+shift+a for reading automatically extracted comments.

Also labels some edit fields.

comment 1:
Might it be useful if getPath and fetchObject moved into api.py?
Maybe they can be reused by other app modules?
They may cause a watchdog timeout, but an app module developer at least has another quick strategy for his/her app.

comment 2:
the ui.messages should probably be localized, but are provided as is for testing purposes.

Thank you for your time.

@nvaccessAuto
Copy link
Author

Comment 1 by pvagner on 2011-09-28 09:34
There is one more problem with poedit while browsing the list of strings there is no way for screen reader user to easily know whether a string is marked as fuzzy.
Is this addressable the similar way?

@nvaccessAuto
Copy link
Author

Comment 2 by pvagner on 2011-09-28 09:46
This is great work, especially theway on how you are locating objects.
Nevertheless I've got Some more comments:

  • should the spoken and brailled strings as well as added control names be translatable?
  • I haven't explored poedit my-self but I am just wondering isn't the path to the object still same if we are considering the main window is focus?

@nvaccessAuto
Copy link
Author

Comment 3 by orcauser (in reply to comment 2) on 2011-09-29 09:40
Replying to pvagner:

There is one more problem with poedit while browsing the list of strings there is no way for

screen reader user to easily know whether a string is marked as fuzzy.

The status line shows the number of fuzzy messages in total, but unfortunately I couldn't find out how to find out if the item we stand on is fuzzy or not.
Maybe asking a sighted person would give us extra information on how this is indicated.

Replying to pvagner:

  • should the spoken and brailled strings as well as added control names be translatable?

Not 100% sure, but remember the poedit interface is also localized, so it might be confusing to choose poedit and nvda in your language and still hear these messages in english.

  • I haven't explored poedit my-self but I am just wondering isn't the path to the object still same if we are considering the main window is focus?

Sorry I dont understand your question.
You dont want me to use api.getForegroundObject()?
Esentially it doesnt matter very much what object you use in the application, as long as it is an fixed ancestor of the object you really want.

Thanks.

@nvaccessAuto
Copy link
Author

Comment 4 by orcauser on 2011-10-09 08:29
After the recent fix to the displayModel.getTextWithFields, neither the foreground nor the background color are useful to us.
They always seem to be white, teal respectively.

The bold property on the other hand is set on messages that are untranslated or fuzzy, so we use that instead.
I added a small beep to indicate that the message needs attension, which is less verbose than if we say "incompleted" or any similar word.

Please test.

Thanks

@nvaccessAuto
Copy link
Author

Comment 5 by fatma.mehanna on 2011-10-09 20:44
hi,
that's excellent work. the beeb sound will indecate that something wrong with the message whether it is untranslated or fuzzy. i think now we can completely know what is related to the messages whether they are translated, untranslated or fuzzy, and if there are automatic or real comments.

@nvaccessAuto
Copy link
Author

Comment 6 by jteh on 2011-10-09 21:42
Note that beeps aren't useful to users who are blind deaf (using braille displays).

@nvaccessAuto
Copy link
Author

Comment 7 by mdcurran on 2011-11-01 00:14
If you wish to keep the beep, it should definitely be implemented as an event_gainFocus on the PoeditListItem NVDAObject, rather than being called from its name property. However, as Jamie has pointed out, the beep is not useful for some people. Perhaps a star (*) character prepended to the list item's name might be enough?
Finally I must point out that the report comment scripts break completely in Windows 8 due to the edit fields being UIAutomation. The path-based way of fetching those objects in poedit.py does not lend itself well to handling different APIs, but its also a bit silly to have to handle multiple APIs when you know that the MSAA/window model will always exist. Perhaps we could mark RichEdit controls as not being UIAutomation to get around this. In deed there are also some other issues with the UIA implementation for richEdit new to Windows8, but we'll have to consider this one carefully.

@nvaccessAuto
Copy link
Author

Comment 8 by orcauser (in reply to comment 7) on 2011-11-27 15:59
Replying to mdcurran:

If you wish to keep the beep, it should definitely be implemented as an event_gainFocus on the PoeditListItem NVDAObject, rather than being called from its name property. However, as Jamie has pointed out, the beep is not useful for some people. Perhaps a star (*) character prepended to the list item's name might be enough?

I will add the star and move the beep to event_gainFocus.

Finally I must point out that the report comment scripts break completely in Windows 8 due to the edit fields being UIAutomation. The path-based way of fetching those objects in poedit.py does not lend itself well to handling different APIs, but its also a bit silly to have to handle multiple APIs when you know that the MSAA/window model will always exist. Perhaps we could mark RichEdit controls as not being UIAutomation to get around this. In deed there are also some other issues with the UIA implementation for richEdit new to Windows8, but we'll have to consider this one carefully.

Sorry, most of this went over my head, what should be done, and where can I find an example of where this has been done before to learn from.

@nvaccessAuto
Copy link
Author

Comment 9 by mdcurran on 2011-11-28 00:51
At this point in time, there's nothing really you need to do. But just be aware that this appModule at the moment does not work in Windows 8. Most likely we can fix this in NVDA internally by disabling UIAutomation for those edit fields.

@nvaccessAuto
Copy link
Author

Attachment poedit.py added by orcauser on 2012-01-19 18:17
Description:

@nvaccessAuto
Copy link
Author

Comment 10 by orcauser on 2012-01-19 18:26
Latest Attachment:
when the listitem is fuzzy/untranslated then:
prepends "* " to the name
beeps on gaining focus.

Please review.

Thanks

@nvaccessAuto
Copy link
Author

Comment 11 by orcauser on 2012-01-19 18:27
Changes:
Milestone changed from None to 2012.1

@nvaccessAuto
Copy link
Author

Comment 12 by jteh on 2012-01-20 00:36
This looks good. Feel free to commit. Thanks for your work.

Just two quick cosmetic thoughts:

  • The copyright line probably only needs to include your name at this point, as I'm guessing no one else contributed any code to this module.
  • Perhaps add a docstring to the app module:[[br]]
    """App module for Poedit """
    I realise that many of our existing app modules don't have this, but I'm trying to get into the habit of doing it for new ones.

@nvaccessAuto
Copy link
Author

Comment 13 by orcauser on 2012-01-20 08:45
d944f97

Thanks.
Changes:
State: closed

@nvaccessAuto nvaccessAuto added enhancement component/i18n existing localisations or internationalisation labels Nov 10, 2015
@nvaccessAuto nvaccessAuto added this to the 2012.1 milestone Nov 10, 2015
@gregjozk
Copy link
Contributor

gregjozk commented May 5, 2020

Hello,

on translation list there has been sometimes asked by translators to improve poedit support in NVDA, due to changes in newer editions of poedit or at least include an addon which was written by neppaly translator and contributer, who died sadly. (I know, that this addon should be ported into python 3 firstly).
just a very kind reminder and plea.
thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/i18n existing localisations or internationalisation enhancement
Projects
None yet
Development

No branches or pull requests

2 participants