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

Missing fullstops at the end of a help messages #4321

Open
nvaccessAuto opened this issue Jul 22, 2014 · 9 comments
Open

Missing fullstops at the end of a help messages #4321

nvaccessAuto opened this issue Jul 22, 2014 · 9 comments
Labels
component/i18n existing localisations or internationalisation task

Comments

@nvaccessAuto
Copy link

Reported by ondrosik on 2014-07-22 10:28
I noticed this during translation. Some help messages have full stop (.) at the end but some don't.
For example:
Reports the comment on the current cell
but
Reports the text of the comment where the System caret is located.
Seems that this is inconsistent in older messages too, for example
Shows the NVDA menu
Shows the long description at this position if one is found.
Reports the current navigator object. Pressing twice spells this information,and pressing three times Copies name and value of this object to the clipboard
I know that this is lov priority, but maybe we should make this consistent later and negotiate, if there should be fullstop at the end of help messages or not.

@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2014-07-28 07:49
I agree that consistency would be nice. For command descriptions, I think we should have full stops at the end.

That said, while it's annoying that it's inconsistent, changing this for older messages would be a huge burden on translators, as they'd have to re-translate all affected messages just because of the added full stop.

@nvaccessAuto nvaccessAuto added task component/i18n existing localisations or internationalisation labels Nov 10, 2015
@bhavyashah
Copy link

Jamie wrote in #4321 (comment) "That said, while it's annoying that it's inconsistent, changing this for older messages would be a huge burden on translators, as they'd have to re-translate all affected messages just because of the added full stop."
Hmm, this might be a valid showstopper for this issue to be taken any further. Thoughts? CC @josephsl and other translators

@josephsl
Copy link
Collaborator

josephsl commented Aug 29, 2017 via email

@LeonarddeR
Copy link
Collaborator

Wouldn't there be a possibility to undo marking all these cases as fuzzy for every language by means of a script?

@josephsl
Copy link
Collaborator

josephsl commented Aug 30, 2017 via email

@LeonarddeR
Copy link
Collaborator

@josephsl commented on 30 aug. 2017 08:13 CEST:

Hi, If so, we run into a state where a translator may modify the Gettext file while this is processing, leading to confused Gettext as to what to do. Thanks.

I'm not sure whether I follow this. Processing these case won't take more than a few seconds, and processed gettext files should be pushed to the translation repository instantly. People should always make sure that they are up to date with the current state of the translation repo before doing any work. And still, if they mark messages fuzzy again by accident, they are likely to be able to fix this by hand, since they already seem to work on translation.

@josephsl
Copy link
Collaborator

josephsl commented Aug 30, 2017 via email

@LeonarddeR
Copy link
Collaborator

May be we should just park this issue until the translation workflow has been moved to github.

@jcsteh
Copy link
Contributor

jcsteh commented Aug 30, 2017 via email

@jcsteh jcsteh removed their assignment Sep 5, 2017
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 task
Projects
None yet
Development

No branches or pull requests

5 participants