i18n-bugs September 2020

i18n-bugs@lists.fedoraproject.org

1 participants
102 discussions

[Fedora-i18n-bugs] [Bug 1853937] ti, tt ligatures (of at least Lato font) loaded without hinting
by bugzilla＠redhat.com 21 Sep '20

21 Sep '20

https://bugzilla.redhat.com/show_bug.cgi?id=1853937 Peng Wu <pwu(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Doc Type|--- |If docs needed, set a value --- Comment #9 from Peng Wu <pwu(a)redhat.com> --- Could you provide the expected result? And how do you produce the sample image? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Fedora-i18n-bugs] [Bug 1853937] ti, tt ligatures (of at least Lato font) loaded without hinting
by bugzilla＠redhat.com 21 Sep '20

21 Sep '20

https://bugzilla.redhat.com/show_bug.cgi?id=1853937 James <james(a)ettle.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Comment|0 |updated --- Comment #0 has been edited --- Created attachment 1699956 --> https://bugzilla.redhat.com/attachment.cgi?id=1699956&action=edit Sample renderings The horizontal 't-crossing' strokes of the ti and tt ligatures are rendered slightly below the x-height, in a manner that is more- or less-visible depending on font size. It's most visible at 11pt. Attached are samples rendered with RGB subpixel anti-aliasing, slight hinting. The issue is visible in the 8, 11 and 14pt samples. lato-fonts-2.015-9.fc32.noarch freetype-2.10.1-2.fc32.x86_64 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Fedora-i18n-bugs] [Bug 1853937] ti, tt ligatures (of at least Lato font) loaded without hinting
by bugzilla＠redhat.com 21 Sep '20

21 Sep '20

https://bugzilla.redhat.com/show_bug.cgi?id=1853937 --- Comment #8 from James <james(a)ettle.org.uk> --- (In reply to Alexei Podtelezhnikov from comment #7) > The glyphs are hinted in the font. It must be Pango which loads them > unhinted (FT_LOAD_NO_HINTING). Please reassign to Pango. Done. I've changed the title -- does this accurately summarise the situation? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Fedora-i18n-bugs] [Bug 1853937] ti, tt ligatures (of at least Lato font) loaded without hinting
by bugzilla＠redhat.com 21 Sep '20

21 Sep '20

1 0

[Fedora-i18n-bugs] [Bug 1678787] Hide languages not available on zanata during the installation process
by bugzilla＠redhat.com 17 Sep '20

17 Sep '20

https://bugzilla.redhat.com/show_bug.cgi?id=1678787 Vladimír Slávik <vslavik(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mfabian(a)redhat.co | |m) | --- Comment #5 from Vladimír Slávik <vslavik(a)redhat.com> --- Got it now. The bug is actually quite fascinating. It can be interpreted in two ways: - Anaconda should not show locales ("languages") that don't have a translation (see above) - The Chinese translation is laid out in a different manner than others and thus prevents successful fallbacks (see below) ---- How this works. Ultimately we try to set the locale specified by UI (whether translation exists or not), and it all bubbles down to setlocale(3). This somehow decides if a locale is valid or not. Then we try to load the translation for that, with gettext. What happens next is that gettext tries to fall back on simplified specifications of the locale (_nl_make_l10nflist, around line 300-ish). What I *think* is the case -intentionally- is that these fallbacks built into gettext have been used in a clever way to make translations match-able to all locales - or rather most of them. For anaconda specifically, the cases are: - English is already the default, so nothing could be noticed without a deep inspection of the texts. - Many languages have precisely one locale so the distinction between the language and a language+territory is moot (Czech, Filipino...). - Some languages have tons of locales but provide translation only for the base language, so all of the locales fallback onto that if selected (eg. Spanish, French...). - Some languages have the bare language translation and then some of their locales have their specific translation too, so everything is translated. (Portuguese, Serbian...). - Some languages have translation per language, and their locales should differ significantly and do not because they all fall back onto the bare language (Punjabi?). - Some languages have only translations per locale, and not all locales are covered, so their fallbacks can't go anywhere (Chinese). Arguably, having zh_CN translations as zh would fix the problem for us. --- The code-based solution would be to add a check if translation for a particular locale exists, and use that when adding locales. The problem with that is that it would have to take into account gettext's fallback algorithm, and I'm not sure if that can be reused. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Fedora-i18n-bugs] [Bug 1678787] Hide languages not available on zanata during the installation process
by bugzilla＠redhat.com 15 Sep '20

15 Sep '20

https://bugzilla.redhat.com/show_bug.cgi?id=1678787 Vladimír Slávik <vslavik(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|anaconda-maint-list@redhat. |vslavik(a)redhat.com |com | Flags| |needinfo?(mfabian(a)redhat.co | |m) --- Comment #4 from Vladimír Slávik <vslavik(a)redhat.com> --- It's probably worth considering why this works for everything else. I think somewhere in the whole works there's a fallback to the language's default locale-translation in case the selected locale is not translated. (See below why this should be the case.) But why does this not work for zh_SG in particular? Mike, could you please check langtable's data if there is anything special for this case? It might be that there's a default missing, impossible, or something along these lines. ---- Notes to self... The offending item as of now is zh_SG it seems. It might be we keep shooting ourselves in foot, as far localization is concerned. In LangLocaleHandler.initialize() we first list languages with translations, then we put these on a list and add locales to these. Except translations are for the "locales", not languages. My terminology might be wrong here, so an example - we detect files for zh_CN and say we have zh. So the whole premise of get_available_translations() might be wrong. It gives us languages (zh), but these are not actually a correct representation of what is available, it's locales (zh_CN) that get translations. Then later we try to rectify that by adding the actual locales to the second list, as sub-items for the languages. That itself is correct, but not enough. We depend on langtable to give us the locales via get_language_locales(), and disregard the earlier-found (non)presence of translations. That adds a dilemma, as LangLocaleHandler is a mixin used in both the welcome spoke and language/localization spoke. The former should filter by available translations (see this bug), the latter most probably not. One way might be to have some sort of filter on WelcomeLanguageSpoke._add_locale(). That might need memoizing as the locales are apparently re-listed on every language change on that spoke. While at it, it might be beneficial to rethink this whole "store stuff in gtk container instead of a python structure" approach. But it might grow the scope too much, too. Regardless of all that, a langtable-only fix can not be ruled out, per the first paragraph. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Fedora-i18n-bugs] [Bug 1690326] Input of Vietnamese string (with ibus-bogo-0.4-19.fc30) deletes all / any character to the left of the cursor
by bugzilla＠redhat.com 15 Sep '20

15 Sep '20

https://bugzilla.redhat.com/show_bug.cgi?id=1690326 fujiwara <tfujiwar(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Link ID| |GNOME Gitlab | |GNOME/gnome-shell/-/issues/ | |619 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Fedora-i18n-bugs] [Bug 1678787] Hide languages not available on zanata during the installation process
by bugzilla＠redhat.com 15 Sep '20

15 Sep '20

https://bugzilla.redhat.com/show_bug.cgi?id=1678787 Vladimír Slávik <vslavik(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vslavik(a)redhat.com --- Comment #3 from Vladimír Slávik <vslavik(a)redhat.com> --- Can reproduce with current rawhide: 官话 is not in the list but 简体中文（新加坡）is, and it is not translated. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Fedora-i18n-bugs] [Bug 1779586] New: [abrt] ibus-table: g_settings_schema_get_value(): python3.7 killed by SIGTRAP
by bugzilla＠redhat.com 15 Sep '20

15 Sep '20

https://bugzilla.redhat.com/show_bug.cgi?id=1779586 Bug ID: 1779586 Summary: [abrt] ibus-table: g_settings_schema_get_value(): python3.7 killed by SIGTRAP Product: Fedora Version: 31 Hardware: x86_64 Status: NEW Whiteboard: abrt_hash:004184fdd6fa1b8e4e49df86a1c57ac5847dd204;VAR IANT_ID=workstation; Component: ibus-table Assignee: mfabian(a)redhat.com Reporter: mfabian(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: dingyichen(a)gmail.com, i18n-bugs(a)lists.fedoraproject.org, kent.neo(a)gmail.com, mfabian(a)redhat.com, pwu(a)redhat.com, shawn.p.huang(a)gmail.com Target Milestone: --- Classification: Fedora Version-Release number of selected component: ibus-table-1.9.21-5.fc31 Additional info: reporter: libreport-2.11.3 backtrace_rating: 4 cgroup: 0::/user.slice/user-10030.slice/session-2.scope cmdline: /usr/bin/python3 /usr/share/ibus-table/engine/main.py --profile --ibus crash_function: g_settings_schema_get_value executable: /usr/bin/python3.7 journald_cursor: s=c0d79f79862b4941981f04495d4f8245;i=8bf219;b=16aabd8bda544929bc6ad65c9e902988;m=37114158;t=5985239b337cb;x=955981e5440c8c5d kernel: 5.3.12-300.fc31.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 10030 xsession_errors: Truncated backtrace: Thread no. 1 (10 frames) #4 g_settings_schema_get_value at ../gio/gsettingsschema.c:973 #6 g_settings_schema_key_init at ../gio/gsettingsschema.c:1253 #7 g_settings_set_value at ../gio/gsettings.c:1578 #8 ffi_call_unix64 at ../src/x86/unix64.S:76 #9 ffi_call at ../src/x86/ffi64.c:525 #10 pygi_invoke_c_callable at ../gi/pygi-invoke.c:690 #11 pygi_function_cache_invoke at ../gi/pygi-cache.c:863 #12 pygi_callable_info_invoke at ../gi/pygi-invoke.c:770 #13 _wrap_g_callable_info_invoke at ../gi/pygi-invoke.c:770 #14 _Py_CheckRecursionLimit -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Fedora-i18n-bugs] [Bug 1158370] list major common keyboard layouts first
by bugzilla＠redhat.com 11 Sep '20

11 Sep '20

https://bugzilla.redhat.com/show_bug.cgi?id=1158370 Sundeep Anand <suanand(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RELEASE_PENDING Flags|needinfo?(jkonecny(a)redhat.c | |om) | -- You are receiving this mail because: You are on the CC list for the bug.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

i18n-bugs September 2020