Created attachment 794162 [details] boxes-in-urdu-in-language-selection-page.png Tested with Fedora-20-Alpha-TC3-x86_64-netinst.iso. See attached screenshot.
This is the translation: #: pyanaconda/ui/gui/spokes/welcome.glade:395 msgid "What language would you like to use during the installation process?" msgstr "کون سی زبان کا اپ استعمال کر نا چاہتے ہیں؟" The translation looks correct in gedit tested on f19, see screenshot.
Created attachment 794165 [details] urdu-translation-looks-correct-in-gedit-on-f19.png Here in gedit, the translation is rendered correctly.
Probably a font problem.
Created attachment 794204 [details] fonts-dejavu-sans-scheherazade.png Screenshot showing that "DejaVu Sans" does not have the glyphs displayed as boxes but "Scheherazade" for example has them. The font looks very much like "DejaVu Sans" in Anaconda. The font in my gedit screenshot is also "DejaVu Sans" but apparently gedit manages to fallback to something else for the missing glyphs.
Created attachment 794205 [details] kate-urdu-dejavu-sans.png screenshot of kate, showing that contrary to gedit, kate cannot fall back to other fonts for the Urdu glyphs missing in "DejaVu Sans".
Fonts we have in Fedora 19 which do support Urdu: mfabian@ari:~/bugs/redhat $ fc-list :lang=ur | grep usr/share /usr/share/fonts/nafees-web-naskh/NafeesWeb.ttf: Nafees Web Naskh:style=Regular /usr/share/fonts/paktype-naskh-basic/PakTypeNaskhBasicSindhi.ttf: PakType Naskh Basic Sindhi:style=Regular /usr/share/fonts/sil-scheherazade/ScheherazadeRegOT.ttf: Scheherazade:style=Regular /usr/share/fonts/paktype-tehreer/PakType_Tehreer.ttf: PakType Tehreer:style=Regular /usr/share/fonts/paktype-naqsh/PakType_Naqsh.ttf: PakType Naqsh:style=Regular /usr/share/fonts/nafees-nastaleeq/NafeesNastaleeq.ttf: Nafees Nastaleeq:style=Regular mfabian@ari:~/bugs/redhat DejaVu Sans does not support Urdu, only Arabic and Persian: mfabian@ari:~/bugs/redhat $ fc-list "DejaVu Sans:lang=ur" mfabian@ari:~/bugs/redhat $ fc-list "DejaVu Sans:lang=ar" /usr/share/fonts/dejavu/DejaVuSansCondensed-Bold.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Bold,Bold /usr/share/fonts/dejavu/DejaVuSans.ttf: DejaVu Sans:style=Book /usr/share/fonts/DejaVuSans.ttf: DejaVu Sans:style=Book /usr/share/fonts/dejavu/DejaVuSans-Bold.ttf: DejaVu Sans:style=Bold /home/mfabian/.fonts/nokia/dejavu/DejaVuSans.ttf: DejaVu Sans:style=Book /usr/share/fonts/dejavu/DejaVuSansCondensed.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed,Book mfabian@ari:~/bugs/redhat $ fc-list "DejaVu Sans:lang=fa" /usr/share/fonts/dejavu/DejaVuSansCondensed-Bold.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Bold,Bold /usr/share/fonts/dejavu/DejaVuSans.ttf: DejaVu Sans:style=Book /usr/share/fonts/DejaVuSans.ttf: DejaVu Sans:style=Book /usr/share/fonts/dejavu/DejaVuSans-Bold.ttf: DejaVu Sans:style=Bold /home/mfabian/.fonts/nokia/dejavu/DejaVuSans.ttf: DejaVu Sans:style=Book /usr/share/fonts/dejavu/DejaVuSansCondensed.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed,Book mfabian@ari:~/bugs/redhat $
Created attachment 816840 [details] boxes-in-urdu-in-language-selection-page-TC6.png The problem still exists in Fedora-20-Beta-TC6-x86_64-DVD.iso
DejaVu Sans font should support Urdu characters. Reassigning
dejavu-sans-fonts-2.34-4.fc22.noarch on Fedora 2 Beta still does not support Urdu.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Updating version to 22 based on comment 9
Sure, however to adding a whole new script can only happen upstream In the meanwhile to actually fix the bug an urdu font needs to be added in anaconda (in default fonts) Scheherazade is probably a good choice – SIL fonts are high quality
Will simply adding sil-scheherazade-fonts.noarch to the boot.iso fix this? Or does something more need to be done to make sure it is used instead of dejavu-sans-fonts? spin-kickstarts will need to add it as well so you should clone this bug for that after answering the above question.
I'm pretty sure it is sufficient for fontconfig substitutions to kick in and have something displayed in urdu Will it be perfectly satisfactory ? Only urdu people can tell
lorax-23.18-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15675
lorax-23.18-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update lorax'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15675
Created attachment 1073925 [details] boxes-in-urdu-in-language-selection-page-fedora-23-beta-rc1.png The problem still exists in Fedora-Workstation-netinst-x86_64-23_Beta.iso Maybe Beta RC1 does not yet have the updated version of lorax?
lorax-23.18-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 1084177 [details] font-mixture-in-urdu-in-language-selection-page-fedora-23-tc10.png Mixture of "DejaVu Sans" and "Scheherazade" fonts. Ugly.
(In reply to Nicolas Mailhot from comment #14) > I'm pretty sure it is sufficient for fontconfig substitutions to kick in and > have something displayed in urdu > > Will it be perfectly satisfactory ? Only urdu people can tell What we see in Fedora 23 TC10 is now an ugly mixture of Dejavu Sans and Scheherazade, see screenshot attached to: https://bugzilla.redhat.com/show_bug.cgi?id=1004717#c19 DejaVu Sans is used first, all glyphs which are available in that font come from DejaVu Sans. Scherazade is only used for the missing glyphs. That surely looks quite ugly. I am not sure whether it is readable, in Arabic script neighboring glyphs "flow" together, probably that won't work well with two different fonts.
I have no idea how to fix that, or even how it is expected to work. But it isn't a lorax problem. It is either going to be Gtk or Anaconda.
(In reply to Brian Lane from comment #21) > I have no idea how to fix that, or even how it is expected to work. But it > isn't a lorax problem. Yes. > It is either going to be Gtk or Anaconda. If the Gtk UI were started in Urdu locale, the fontconfig substitutions would work to select a good font for Urdu. But the UI is already running when one switches to Urdu in the language selection. So Anaconda would need to switch locales somehow and re-initialize the fonts.
(In reply to Mike FABIAN from comment #22) > > It is either going to be Gtk or Anaconda. > > If the Gtk UI were started in Urdu locale, the fontconfig substitutions > would work to select a good font for Urdu. That's a simplistic solution. Of course it would work but only because system locale is the last-ditch fallback when the app is too dumb to tag text runs with the correct locale. The text stack is perfectly capable to mix text runs in different locales, it's a hard requirement to be able to edit multilingual documents (very common in a globalized world). Unicode does not solve everything, human scripts overlap, there is no way a system can reliably display unicode text without some form of locale tagging by the text author. (this BTW is why windows i18n works, and *nix i18n does not, the windows input switcher was written for office. Those guys did manage complex human text and understood switching input means switching locales, with keyboard layout a locale option. While *nix people still think locale can be deduced from layout or text encoding, 20 years later, X11 mistake grandfathered in Wayland)
(In reply to Nicolas Mailhot from comment #23) > (In reply to Mike FABIAN from comment #22) > > > > It is either going to be Gtk or Anaconda. > > > > If the Gtk UI were started in Urdu locale, the fontconfig substitutions > > would work to select a good font for Urdu. > > That's a simplistic solution. It is enough for Anaconda though. > Of course it would work but only because > system locale is the last-ditch fallback when the app is too dumb to tag > text runs with the correct locale. The text stack is perfectly capable to > mix text runs in different locales, it's a hard requirement to be able to > edit multilingual documents (very common in a globalized world). Unicode > does not solve everything, human scripts overlap, there is no way a system > can reliably display unicode text without some form of locale tagging by the > text author. If you are writing a web page, you can of course mark text with stuff like <span lang="ja">直</span> to make sure that a Japanese font is used for 直. At least in firefox and probably most other browsers this works. But for an installation in Urdu using Anaconda this is kind of overdoing it. What else except Urdu (Arabic Script) and some ASCII do you expect to appear during an installation using Urdu? If there is really some place during the installation where truly multilingual stuff is displayed, we could think of using such markup there. The only such place I can currently think of is the language selection at the beginning where all language names are shown in their native script. The fonts used for this might not be optimal for each language at the moment. Although no really serious problem has been found in that page so far.
Is this a problem on other screens or just the welcome screen?
(In reply to David Shea from comment #25) > Is this a problem on other screens or just the welcome screen? I tried again and looked at the pages coming after the language selection. Unfortunately there is so little translated text in Urdu there that it is hard to tell. There is some translated text in "Software Selection"and I found some where the root password can be entered. I think we see a mixture of "DejaVu Sans" and "Scheherazade" there as well. I’ll attach a screen shot in the next comment. Anaconda does not change locales and reinitialize the font stuff when proceeding from the welcome screen, or does it?
Created attachment 1085442 [details] urdu-anaconda-f23-root-password-possibly-font-mixture.png
(In reply to Mike FABIAN from comment #26) > Anaconda does not change locales and reinitialize the font stuff > when proceeding from the welcome screen, or does it? It resets $LANG and calls setlocale, but it does not do anything to re-initialize gtk's understanding of the locale because that is not possible.