[Fedora-i18n-bugs] [Bug 1853937] ti, tt ligatures (of at least Lato font) loaded without hinting
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1853937
James <james(a)ettle.org.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |caillon+fedoraproject@gmail
| |.com,
| |gnome-sig(a)lists.fedoraproje
| |ct.org,
| |i18n-bugs(a)lists.fedoraproje
| |ct.org,
| |john.j5live(a)gmail.com,
| |mclasen(a)redhat.com,
| |pwu(a)redhat.com,
| |rhughes(a)redhat.com,
| |rstrode(a)redhat.com,
| |sandmann(a)redhat.com,
| |tagoh(a)redhat.com
Component|lato-fonts |pango
Summary|Inconsistent rendering of |ti, tt ligatures (of at
|ti, tt ligatures |least Lato font) loaded
| |without hinting
--
You are receiving this mail because:
You are on the CC list for the bug.
3 years, 7 months
[Fedora-i18n-bugs] [Bug 1678787] Hide languages not available on zanata during the installation process
by bugzilla@redhat.com
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.
3 years, 7 months
[Fedora-i18n-bugs] [Bug 1678787] Hide languages not available on zanata during the installation process
by bugzilla@redhat.com
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.
3 years, 7 months
[Fedora-i18n-bugs] [Bug 1779586] New: [abrt] ibus-table: g_settings_schema_get_value(): python3.7 killed by SIGTRAP
by bugzilla@redhat.com
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.
3 years, 7 months