 This little delay, welcome to the second session about one of the non-Western language groups. I'm Ayal from both the Hebrew and the Arabic user groups, and we are talking about the state of right-to-left language support in Libre Office. And we're in 2022. The last time this session was given was in 2018 in Tirana, so four years since this last update. What we're going to do today, we're not going to talk about right-to-left languages. I hope you all know what those are, or at least, anyway, not a lot. We're not going to talk about how to switch between languages and what Libre Office already has. But I am going to remind you about where we need support for these languages. We're going to go over a few bug statistics, some important fixes in the code, improvements to right-to-left language-related functionality over the past several years. And we are going to talk about challenges that are outstanding today as well. So right-to-left languages, oh, this shows some stuff from the previous... Ignore the example column except for the first two cells for some reason. Well, just ignore it. Anyway, so the most popular written language or script is Arabic, and a lot of languages use it, including in different parts of the world, not only in the Arab East and Central and Western Asia. There's the Nicole language or script that's used by languages in Africa, which is the second largest. There's the Adlam script used by the family of languages. And unfortunately, I've not seen a single person in this conference who uses any of these scripts, except perhaps for our Turkish friend whose name escapes me. I'm sorry, and for him it might be a second language, but no native language speaker from any of these groups. You also have Rohingya, then you have Hebrew, which is well over-represented with me being here. We're only eight million people who speak it natively. And there are actually more, both languages and scripts. And later, if you watch these slides and want to see the long list, then it's on w3.org, they have a nice list of these. What's important for me to note is that not a small percentage of the population of this planet use write-alive scripts or writing, and something like 8% of the most popular written languages, those with over 10 million speakers. And it's even higher for secondary languages. But if we look at the number of write-alive language users among overall users of LibreOffice, this is very difficult to estimate, and I've cut a few slides where I was making a backhand cocktail napkin estimate, so you won't have that. But it is low relative to the percentage in the overall population size, and it's still low even if you want to normalize it, say for development indices or number of people who use a computer at all or things like that. It's still low, so that's a problem. Write-alive language support. This few slides were actually a better fit for the other room, and less for the more technical nitty-gritty room, which we're in. But it's not just in the code, so we need the document model, the structural representation of it, the ODF specification, the way it's rendered both on screen and in print, different gadgets in the document, like comments and footnotes, need aspects of functionality that are write-alive specific. And that's not all. There's actually a lot more, so there's the user interface, which is still within the application, and even there there are several aspects of the user interface which require some functionality that is write-alive specific. But no less important is help and documentation, the websites of our projects and related sites, the platforms we use for discussion, the Ask website, Telegram channels, IRC, and even programs that we have for opportunities that we offer, or that the document foundation offers for training or for certification, need to have at least some aspect of cognizant awareness of write-alive issues. And before I get into the more application-specific aspects of write-alive support, I need to make the point that write-alive languages are generally not well supported outside of the applications themselves. This is not an accusation because this is also the responsibility of our language communities, some of which don't even exist, but even the ones which do. We have websites, like localized websites, which are entirely missing or are out of date. We have web pages which are the target of links in the applications which don't exist in localized versions. We don't have any translated user guides, not even for older versions of LibreOffice, and the relevant sections of ask.libreoffice.org are either missing or have very few questions. But after this rant, I'm going to switch over to the aspect of support that's within the applications themselves, within the different modules, so we're putting that aside. And also the negative tone, because within the application things are better and improving, certainly not perfect. But let's talk about what happened over the past four years. Since it's been four years, we're not going to be covering everything or going into the details. So first, where you can track this progress yourselves if you want to. Some of the aspects of support are not trackable, especially those that are not within the applications. But if we're looking at in-application technical issues, they are tracked on the Document Foundation's bugzilla, and there are several, there's more than one, several meta-bugs. There's the RTL CTL, RTL is for right to left, CTL is for complex text layout. There's also RTL UI, which are meta-bugs. RTL CTL is the equivalent of the CJK meta-bug which Shinji mentioned in the last presentation. And we also have language-specific issues. And we have meta-bugs for Hebrew, for Nicole, and a single meta-bug for Arabic and Farsi, and meta-bug for languages which are relevant to minority groups in China, minority language communities within China. Not that many issues there, unfortunately. There is under-reporting that corresponds, I believe, that corresponds to the under-representation in our active user community and in the user statistics in general. And of course, each of these meta-bugs attracts the actual bugs. Just to give you a sample, because we're not covering all the bugs, in the 2017 State of Right to Left support talk given by Leo Kaplan, who I want to thank also for the work on this presentation, which he helped me with. He listed six typical bugs, three in Ryder and three in Impress. That were bugging, well, not just him, but not necessarily the most important bugs, but important ones. And by 2018, a few of them were fixed, and by now they've all been fixed. That doesn't mean that all Ryder left bugs have been fixed, but at least putting things on the table here and attracting developer focus does have a positive effect. So you can see when more or less each of them was fixed. Hello statistics for you. So 69 Ryder left bug fixes within the span of these four years. And these bugs, about half of them were filed within that period. That doesn't mean they appeared within that period, just filed within that period. And about half, a little less than half are older bugs with respect to components. So the almost a majority, almost half of the bugs were Ryder bugs, Ryder specific. Eight of them Impress or draw, seven and calc. Eight bugs were assigned the UI component, but we could actually associate them with more or less with a specific application. So about the same distribution. No base bugs, by the way. And of course the Impress bugs are also relevant to draw, mostly. Seven bugs were project-wide, so regard all applications. And we have some smaller categories with fixes in there. Now what kind of bugs were fixed? There were issues with the display right to left text and cells and calc. There was some navigation issues. But over the past year, so since 2021, not a single bug related to calc was fixed. In Impress, the layout issues were even more significant. I think in Tirana, Leon mentioned that. So there's been significant improvement there. One issue in animation, one crash, one powerpoint import issue. And now if we go over to Ryder, more than half the issues regard the import of DocX and RTF. And that's not necessarily because there aren't many issues importing powerpoint. I think it's mostly because people don't do that as much. But definitely if you were in Gabo's interoperability session, he also made that point. And some UI issues, behavior with selections and also layout in bottom to top left to right. And project-wide issues, which are a bit more interesting. So we had some issues in spacing when you have both left to right and right to left issues. I'm sorry, text within a text box. There's old Hungarian, so there's a script that was used in the past in Hungary that is written from right to left. Sometimes you couldn't use it at all, and that was fixed. And some cursive control trouble. Oh. So yeah. Nastalik is a kind of Arabic font and there was a rendering issue there. So I'm not going into the details. That just gives you an overview of what kinds of things were fixed. I do want to highlight a few of the issues that were fixed because they're interesting to look at, not just as issues, but also as a process. The first issue is, or the developers and designers worked on, it was mostly a design task, is reworking the dialogue that we used for font selection. And this is the bug number. And Xinqi actually showed you, let me see if I can get a mouse. So let's go through the text first and maybe we'll see the before and after pictures. So the situation we had was that it was decided that we need some work on the font selection dialogue and there was a commit. And the design team was involved in the change of the dialogue design. And it did mean an improvement in the user experience when you had multiple language groups enabled. So here I actually do want to click the link. So in Western only, this is the font selection dialogue if you only have Western languages enabled. And this is the baseline. It's kind of reasonable. But for another language group, and here you see the text in Japanese, so never mind the Japanese, pretend it's in English. We didn't get, we couldn't use the, or we wouldn't use the full area of the window or the window pane for each of the language groups and we had to fit and we were fitting all the features of the font for each of the language group in the same dialogue and so less area for each widget and it was kind of, it feels crowded. And the idea was to change it. But the thing is the change resulted in a situation where if you also had CGK or right to left languages enabled then you can no longer see the font that was selected, the non-Western font that selected when you opened the dialogue. And the thing is, which is annoying, process that led to the initial design change and commit was somewhat flawed. It was flawed because even though the CGK user group was consulted because of either a miscommunication or there was not, weren't active users when this question was asked, then the feedback on the suggested design either was not made or did not make it into the decision-making process. And so the commit was made. And our group, so the right to left language specific groups nor the general RTL group, we were not consulted at all. Not sure why. Not the designers or whether. But then, so it was reported as a regression after the commit had already gone in. So that was a bad part of the process. The better part of the process is that once the regression was reported, we caught up on the discussion that should have happened before and happened on the regression bug page. And Tey Kotitze suggested an alternative design, a new layout which was well received by all interested parties, I hope everyone that I can think of. And the new design is something like this, so it splits the dialogue in half. So you get sort of a vertical split and then you get not all the area for each of the language groups, but each of them gets more area and more visibility of the font family list at least than was the case before. And we like this. It's not perfect when you enable all three language groups, but it's certainly much better than the change that had gone in before. But of course it's also a lesson that if we do the process right the first time, then we don't need to wait for the regression and people don't have to complain and it will take less time overall, et cetera. Another thing I want to highlight is a fix to a justification issue with the Arabic script. It's a justification mechanism which involves lengthening horizontal lines in letters rather than using spaces. And I'm not going to go into the details of what that means because there is another session, the following session is exactly about that. It's by Hussein Nureka. But the bottom line that I want to mention here is that Khaled Hosni in one fell swoop, one commit fixed eight different right to left, well, justification related bugs and that's legendary and awesome. But there's a bit of work that remains following that change and if you want to see what that work is so this is the link to the bug. So this is an example of how sometimes if someone takes the time to do a deep dive and make a fix that's very deeply into the code and never mind the details, then you can fix a whole bunch of issues rather than aiming for workarounds or something that's specific to this situation or that situation. So that's definitely, if we can have more of those that would be great. One last issue I want to highlight that was fixed is a change of the default fonts for Arabic and Hebrew by Yusuf Philips who was no longer very active but was more active a few years ago. Several bugs that relate to that. There was zero development effort here so nothing was changed in the code but these issues had very high visibility and the changes had very wide effect including to our public image. There was a long community process of discussing what would be best what are the best combinations. We had candidates so there was more than one round and there were also some supporting fixes to rendering that allowed this to happen for some of these fonts. However, this process was not finished so I want to ask people in this room and out of this room to help me push for this process to finally be finished and it's not finished because we're missing community feedback. The Arabic language community has not been very active and I'm not a native speaker so I don't feel qualified to make the choice so this is not done yet despite the great work that has already happened. Finally, some with the say five or six minutes I have left some noteworthy outstanding challenges things that are not fixed. So perhaps the most visible one is that damn PDF text run flipping issue. So if we take the document on the left and we save it to a PDF and we open it again in Ryder or in Press or wherever we get the document on the right which also has the wrong font but that's not the bug I'm talking about. The thing is the characters appear in the opposite direction. So look at this square character a final man in Hebrew so here it's on the right instead of on the left and here the Arabic is also reversed so this is super annoying effectively means we can't open PDFs with right to left content can't even view them certainly can't edit them so there is a tender for this to be fixed this year but all of the tenders are blocked because of some secret legal trouble that I don't know what it is what that's about but for some reason it's preventing us from getting the fix that we want that we need to work on it and maybe if you can accept that thing from whatever legal reason it is that tenders aren't happening we really want this to go ahead. Another issue which is more fun the rest are more fundamental ones that have seen no work or almost no work is the issue of start and end versus left and right and this is the bug number so if you think about paragraphs that are written left to right they start on the left of their first line and they end on the right of their last line but right to left paragraphs well not necessarily in English but if a paragraph is right to left it starts on the right edge of the first line and it ends on the left edge of the last line but we have a lot of settings in the UI and possibly also in the format I'm not sure because I haven't looked into it certainly in the user interface which say start and end but actually main left or right or maybe not and it's not consistent and sometimes you want all options so for example if you're looking at paragraph alignment we have left alignment and we have right alignment but then if I switch the direction but maybe I want my paragraph to be aligned to the start and right now I can't do that when I change the paragraph direction I also have to change the alignment so the alignment is visual and not logical in that sense so we need two extra options here but if you look at the last line part here you do have start or end so here we do see some partial work towards this goal but it's not uniform in other cases we see this in the other direction so the UI says before or after rather than left or right but it can mean either left or right depending on what the direction is and you're not sure exactly what it's going to do so you have to guess where the column will be at it sometimes it is a better idea to say to the left or to the right and this also depends on what direction is the table's column progression but actually we don't have a well-defined concept of table column progression at least not in the user interface and what happens if you take one column and you make it right to left but the column progression direction of the entire table so I don't even know what the answer should be but it should be something and there are a bunch of these issues throughout LibreOffice that need to be addressed at some point and the last issue I will highlight specifically is deepening the support for languages not for specific languages for languages so LibreOffice does not let you set the language of a piece of text which might sound weird to you but it's just the case LibreOffice doesn't really support languages not really it recognizes language groups but it doesn't properly support languages but what if within the same language group I want to distinguish what I do with Arabic and what I do with Hebrew or even in the western language group I want to do something for Russian and something else for English and the very specific example I want to define my paragraph style or my character style to have a different font for Russian and for English or for Arabic and for Hebrew this is not supported at least not in the terms of the user interface I don't know about the the ODT format hopefully it's better there but there's no visibility for it in the user interface and I also don't know about the code yes, Regina I'm going to the character style when you consider the language in English in the character style in English I see a lot of problems there oh but when I said a character style for several characters some of them might be in English and some of them might be in Russian or in Hebrew no I do not I want the same style to encompass font and from right now the style encompasses font information for the different language groups I can have a different font set for western characters and for right to left characters and for CJK characters so three settings but I need a per language setting same thing for paragraph styles by the way challenges which I'll only sketch briefly there are a few RTL issues defined as severe which are open compatibility with MS office formats is very painful in general but it's even more painful for right to left and for a lot of people okay this is only anecdotal this is not a proper survey a lot of people have told me that the reason that they will not switch from Microsoft Office to Libre Office for right to left incompatibilities with their file formats and then there are the less represented languages which have their own idiosyncratic features among the right to left languages for example in ancient Tibetan the entire document is a single paragraph and there is a problem when you have a single paragraph over say 50 pages Libre Office doesn't like it that much and that makes some Tibetan texts I can only say because the bug says that I've never worked with Tibetan myself not usable so different languages have their own like weird idiosyncrasies we shouldn't wait for users to report these issues there should be at some point some effort to go over different languages and at least you know just from reading the Wikipedia article which is you can tell that oh this might have this issue this might have that issue and not wait for the bug report and finally the number of bugs has increased significantly 4 years ago sorry number of open bugs it was 72 4 years ago now it's 195 with 21 unconfirmed bugs it's more because that under recording has lessened rather than that a lot of new bugs have suddenly materialized but there are there is a large number of write-a-last specific bugs and it's increased and it might increase further the more people use non-writer apps and import PowerPoint and things like that so thank you for that and see you next year in a few years who knows