@egli and @bertfrees This table appears to be ready for review. This is the coolest table here on Lib Louis! you guys are heroes for the work you do here.

@egli and @bertfrees I believe these tests are correct and that this table is ready as well. I really appreciate your help with these.

I have been hesitant to add this table to Liblouis. It is the first time someone wants to add a table that is just a simple aggregation of a number of other tables. So I thought we had to think this through carefully. Since this use case seems such a common thing, I'm a bit afraid that adding this table could set the stage for more contributions of that kind. E.g. any use case for studying language X for someone who's native language is Y, is a possible candidate for a new table. We can't say no to such a contribution if we say yes to this one. Of course I understand the usefulness of such tables, but on the other hand we need to be careful to keep the table selection as simple as possible for users.

We also need to ask ourselves whether something is really in scope, before trying to support it. Even if it is simple to do. For instance, adding a table that aggregates different braille codes for different scripts (distinct Unicode ranges), is straightforward. But what if we want to add a table that can handle different languages that use the same script? That's not straightforward at all, and it's a typical case that we consider to be out-of-scope. We'll say that the input document should be marked up with the correct language information, so that software can make use of this information to switch Liblouis tables. Now my question is: if supporting multiple languages with the same script is out of scope, why would supporting multiple languages with different scripts have to be in scope?

Because of how Liblouis works internally, combining tables is indeed very simple. You just compile the rules of the tables, one table after the other. But instead of adding tables that do this simple thing using the includeopcode, perhaps we should provide something in our API for it, to have a generic solution. We kind of already support it, because a table can be a comma-separated list. But for those who select tables through metadata (which is the recommended way), no such feature exists yet.

@bertfrees I think a way to do this through the API would be the best solution. That way there aren't a lot of extra tables that are just combinations of existing ones.

To be honest this is a much better solution and we definitely support it.
@yeatersink was wondering if there is any way he could use these tables together until such a feature is added?

@bertfrees is there any thing we could do to get this started and @yeatersink what do you think?

@paulGeoghegan If it is possible to select multiple tables in Lib Louis already, then we should ask @LeonarddeR if he is willing to do his majic on NVDA to allow this feature/ functionality.

While this is supported in the API already, I really prefer an approach that is supported by liblouis from an user experience point of view. Note that not only NVDA is using liblouis, we have to think about JAWS, iOS/macOs, Windows Narrator, etc.

When I mentioned by idea of enhancing the API, I hadn't really considered that you'll not use this API directly, but depend on other applications such as NVDA to make use of this API. So other applications must also acknowledge the need for implementing such a feature, and think about a suitable user interface. Perhaps that is asking for too much.

My main concern was that we must take care to keep the table selection as simple and failproof as possible for users. So let's focus on finding the best user experience for a minute and forget about an API for it.

If you as a user would have to choose a suitable table, but you might not know yet which tables Liblouis provides, what would be the most effective way to make the best choice?

I've been thinking in terms of a dropdown list, which is probably what a lot of applications do. A dropdown list that contains all of the Liblouis tables is huge. We provided the "index-name" metadata to help applications manage it. In most cases, when sorted by index-name, all the interesting tables will be grouped together, which makes it easier for the user to find the right table, even if there are several variations of it.

But index-name does not solve everything. What if someone is looking for this "ancient language studies" table that Matt and Paul are committing? Where does he start looking? It's not as straightforward as looking for an English table. A good user interface could e.g. benefit from a multi-step selection process, where the user would first select a language, and is then presented with a filtered list of tables. Whether the user selects Old Hebrew or Akkadian in the first step, he will always be presented with a short list that includes this table.

So in that regard, it might not be such a problem to have a lot of tables, as long as the descriptions of the tables are clear and unambiguous. We would however rely on the applications that use Liblouis to present the best possible user interface using the table selection features that Liblouis provides.

@bertfrees I think this is a good approach. I personally don't know a lot about languages so even for others like me this would make the whole process far more intuative and user friendly.
I can create a new issue to discuss this further if you wish?

@bertfrees This is a great idea. Maybe we could have some "General" terms to help users find the languages they are looking for. For example, "Ancient Languages." Then this would open up to all the ancient languages that they could choose from. Another could be "European" or "Middle Eastern"

Once the user chooses that general category, then they could choose their specific tables that they would like. This would be helpful with Spanish for example. Spanish has several variations. Is it Mexican, Cuban, Columbian, or Spain. Having categories like this would help the user find the exact table they are looking for.

They could choose European, then choose Spanish. Then they would know that this is Spanish for Spain. The same way for Mexican Spanish. They could Choose North American and then choose Spanish, then they would know that this is Mexican Spanish for example.
Maybe a table would find itself in a couple of different categories. For example Greek would have a modern and ancient. But the user could Choose European category, then choose Greek, and then be able to pick modern or ancient. But if they are looking to study Classical Greek or Biblical Greek, then they could Choose ancient languages, and then just choose ancient Greek from their as well.

I desperately need access to all of the ancient languages on the same page because I am teaching at several institutions in a couple of different countries via Zoom. We need the ability to read ancient languages in the context of modern languages. What I mean by that is being able to read a Grammar in Modern English or German that teaches ancient Greek or Hebrew. Also Dictionaries are a major issue as well. They are written in English but have the words in many different languages.

Working on this project will completely open up a new level of access academically because we will be able to read and write on the internet and in MS Word in a way that we have never been able to before. We will be able to do this with multiple languages, with both speech and braille.

Using this method will allow users to choose specific tables in lib louis for their specific interests. And allowing multiple Tables to be utilized that the same time would be life changing for bi- lingual or polyglots like myself that rely on this for education and job.

I cannot over emphasise the importantance of this project. @LeonarddeR Will this work with NVDA?

@paulGeoghegan Yes, feel free to open a new dedicated issue. I'm not sure if anything new is required in Liblouis though. It's more of an issue of user interfaces in other applications. For the user experience of selecting a table we are highly dependent on these other applications.

@LeonarddeR What are things that NVDA could do to improve the UX?

@yeatersink By "general terms", are you thinking about keywords? Like in keywords in an HTML page for discovery by seach engines? Liblouis already kind of supports this in theory, through the support for metadata fields with only a key but no value (see the user manual), but AFAIK this feature is not actually used in any table, so for sure applications don't use it. Note that keywords might not even be necessary if applications use the "display-name" field in their searches.