-
-
Notifications
You must be signed in to change notification settings - Fork 626
-
-
Notifications
You must be signed in to change notification settings - Fork 626
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
Add a generic way to expand symmbols regardless of translation #16739
Comments
@LeonarddeR, thanks for having opened the issue. I would rather have described the use case, before describing a solution. |
Greetings, @CyrilleB79 I will present the problem, then the proposed solution: 1 The problem. NVDA already has a automatic language switching feature, which allows this to happen with the languages NVDA already reconizes. Adding new or additional languages should not be a problem. 2 The Solution: What I would like to see is to be able to add a new language to NVDA for each of the languages that we need. NVDA has an automatic language switching feature which will accommodate several languages on the same page. It seems that if we add a new language for the languages that we have written braille for, then this will present the most natural and helpful solution. The lib louis tables are already in NVDA, we just need speech. This is why we opened this issue, and created a pull request. We have tested the characters and symbols for all the languages by adding them to our English locale on our own personal computer. We have created locale folders for each individual language already. We used the NVDA Speech synthesizer, and it speaks the characters, when they are part of the English locale. What would be optimal is if we can use NVDA, Microsoft voices or the eloquence tts to simply speak what the characters are. But also recognize them as their own language. This way we could check a box to tell NVDA what language it is or what language to speak. For example: I know we can work this out. Please help me, I desperately need this for school, and Leonard is going to be needing it in the fall for his school as well. |
@LeonarddeR This would actually be a great solution. I'm actually learning Spanish at the minute and it would be nice to be able to enable something that could tell me when I encounter a Spanish n which NVDA currently calls a regular n. I love the idea of being able to have a list of options in terms of character sets that are currently enabled. It would be great if we could have a sub-menu inside settings or something that could have a keyboard shortcut for easy access. |
Some thoughts.
|
My example was just an example of how others could use it because I just love the idea of having support for different character sets that you could enable and disable when you need them. Yes I am using one core so I might try out Espeak. |
The solution proposed by @LeonarddeR seems promising because it takes into account the fact that the names of characters may have various names in different languages (e.g. difference between English and German names). On the opposite, the solution provided in the PR was not adaptable for users speaking a language other than English. |
@CyrilleB79 to be honest it might not be either way. For example the Akkadian language character names are defined in English so if you are a non-english speaker then you may not understand them. This does not apply to every language but to a lot of them. This solution would however allow for a solution that would allow other language users to at least enable other character sets if they wish. |
It is common sense that if a symbol is not defined in a locale, English is used as a fallback. Also note that enabling these additional character sets would be opt-in, they'd still be disabled by default. |
@LeonarddeR exactly. I just wanted to make it clear to @CyrilleB79 that they would technically be language-specific. |
It was clear to me and that was the sense of my comment #16739 (comment). To be extra-clear, this new subset of characters should be provided in English and the opportunity should be offered to translators to translate them. If they don't, the character's name will fallback to English. |
@seanbudd Curious to know what you think about this approach. Would NV Access accept a pr for this? |
I agree this would be a huge improvement in screen reading different kind of content.
But note that in case of mathematical symbols at least, I added many of them already to the symbols.dic some years ago, so they are translated in many languages now. We should be careful not to cause conflicts between the current symbols.dic file and the optional symbol dictionaries. |
@LeonarddeR - feel free to open a PR |
@Adriani90 This is exactly what I had been hoping for. A method of adding various symbols in this exact manner. @LeonarddeR How do we move forward? I am ready to get rocking and rolling. @paulGeoghegan get your boots on brotha. @seanbudd thanks for the help and @CyrilleB79 you have been a blessing. |
I think best way would be if you could provide just one symbols dictionary that contains all the symbols you'd like to add, then I'll plug it into a pull request I will create later this week. |
@LeonarddeR is it going to be formatted like the regular symbols.dic file? |
Yes, there won't be a difference in format. |
@LeonarddeR we have encountered a problem. We have multiple some files that contain the same characters but they have different names because they follow different systems. For example Akkadian has 2 systems for naming the characters but we can't put them both in an ancientLanguages.dic file. |
@LeonarddeR we could just have an ancient languages category and then have a checkbox for each language. That would totally mitigate this problem and would reduce the chance of symbols conflicting. |
Wasn't the problem with Akkadian that there is an English and a German system? In that case, the English file would belong in a file for the English locale, but the German system in a file in the German locale folder. |
@LeonarddeR I really appreciate your help brother. For the sake of clarity, The Akkadian is not specifically based on the language like English and German. It is more a US system vs a German System. In other words, they both use the same unicode characters. But the difference is that the US system will describe the character where the German system has a Name for the character. For example the US system will call a character a, "A times a." And the German system will call that character an "Eduru." Both systems have different braille as well. Both english speakers will want access to both of the German System and the US system. and German Speakers will want access to both systems as well. Especially since the German system relies heavily on the US system and ORACC refers to both systems. So having the ability to choose one, and then have the same access to the other is vital. It Would be way better to have the ability to select either the US system or the German system in this "Ancient languages" category." The same problem for other languages as well. This same problem will arise with Greek and Coptic. It would be better to have the ability to choose one or the other, especially since they use the same alphabet. In fact, there are several languages that have this same type of issue, and having the ability to select a different variation of that language would be huge! This is breaking into a whole new level of academia my friend, and you are in the beginning of the break through. You are a hero bro. Your help is very much appreciated. |
This gets all pretty complex. I'm trying to translate this to a user experience that allows one to enable/disable dictionaries, but what if one enables both Akkadian systems? So may be we should go even more generic and aim for a method where add-ons could provide custom symbol dictionaries. |
@LeonarddeR We actually thought about a ancient language add on, but to be honest, this idea that you have i think might be better. Especially if we have other categories for Music, Math, and other sciences. To answer your question about someone enabling both systems of Akkadian, i do not think that would ever happen. It is usually one or the other. However, we would want the ability to easily enable one or the other. I am convinced that the same would be true for Greek and Coptic, Modern Hebrew and Biblical Hebrew etc. Even if we have an Ancient Language add on, we would still need the ability to choose one system or the other. And we would still need the ability to read any material in our own mother tongue and be able to engage with ancient languages. Especially in a learning environment, such as taking a Hebrew class, even though we mainly speak English. I think that your idea here is best. but where there might be a conflict with unicode characters, i.e. 2 systems of Akkadian that share unicode characters, only have the option to choose one system or the other, but not both. This would work with Lib Louis tables as well. What do you think? |
But what if we don't want to put the burden of maintaining all those dictionaries upon the shoulders of NV Access? |
@LeonarddeR let me just make sure I'm understanding how this would work. |
The categorization is up to NV Access/the add-on store, but otherwise, yes. I will try to come up with a prototype later this week. |
Is your feature request related to a problem? Please describe.
There are several requests to expand the symbols file, such as #6904, #5194, #16720. They all seem to stall on the concern that adding additional symbols will break speech for some languages.
Describe the solution you'd like
Based on the way cldr was added to NVDA, I propose making that logic more generic, i.e. by adding more additional symbol dictionaries next to cldr that can be enabled/disabled from a checkable list in the speech settings panel. So instead of having the
Include Unicode Consortium data (including emoji) when processing characters and symbols
checkbox, add a checkable list calledAdditional symbol processing dictionaries
that contains theUnicode Consortium data (including emoji)
item, among others.Additional context
In #16732, @yeatersink proposed adding some symbol dictionaries for several ancient languages. I think that we follow the approach as outlined above, we could create an ancient languages symbols dictionary that contains all these symbols.
The text was updated successfully, but these errors were encountered: