Bug 154185 - nautilus is pulling in AR PL KaitiM font for zh_TW
nautilus is pulling in AR PL KaitiM font for zh_TW
Product: Fedora
Classification: Fedora
Component: nautilus (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
Depends On:
Blocks: FC4Target
  Show dependency treegraph
Reported: 2005-04-07 21:22 EDT by Leon Ho
Modified: 2013-03-05 22:43 EST (History)
3 users (show)

See Also:
Fixed In Version: 2.10.0-4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-11 10:34:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch (1.36 KB, patch)
2005-05-10 14:46 EDT, David Zeuthen
no flags Details | Diff

  None (edit)
Description Leon Ho 2005-04-07 21:22:13 EDT
Description of problem:
Currently in zh_TW environment, nautilus is using KaitiM for the font which is
not unify with all other gnome desktop parts. (Other are using Mingti, which is
by default)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. choose traditional chinese in gdm
2. look at nautilus
Actual results:
KaitiM is used

Expected results:
Mingti should be used

Additional info:
Comment 1 Akira TAGOH 2005-04-12 02:12:54 EDT
Because zh_TW.po has:
#. Translators: please note this can choose the default font and the size. e.g.
"Monospace 8". Please do not translate "Sans". In most cases, this should be
left alone.
#: ../libnautilus-private/apps_nautilus_preferences.schemas.in.h:70
msgid "Sans 10"
msgstr "AR PL KaitiM Big5 10"

should it be reverted to Sans 10?
Comment 3 David Zeuthen 2005-05-03 11:36:42 EDT
I'm not sure why upstream did this. Do you know, Alex?
Comment 4 Alexander Larsson 2005-05-04 04:16:46 EDT
Here is the upstream bug that initiated the change:


I really don't know if this change was right in general, because I'm not very
good at i18n issues. However, the sun guy requested this, so it was accepted.

However, the zh_TW change was made by the zh_TW translator, for reasouns unknown
to me. The translators work separately, and I don't get told of such changes.

Maybe we should bring this up on the gnome translators list?
Comment 5 Leon Ho 2005-05-04 21:24:55 EDT
Alex, generally this method was used couple years ago (when we still using x
fontset) because we do not have a good font management system. Now with
fontconfig, the system default should just default to whatever we specify Sans
to fallback to. Any configuration should made in fonts.conf.

Currently for the po substitute method does not promote consistency, and the
decision on how desktop look like will be finalized by translators. It maybe
translator's personal perference on preferring that font, or some other reason.
However this also leads when a system with nautilus does not have that font, the
desktop will break.

In translator POV, they will fill in what they can in po files. So we ideally we
should revert the change within source  file. Otherwise we need to remember to
check on nautilus default fonts for 14 languages everytime GNOME release a new
version, and then revert this change if needed. This may not be ideal for us.

Comment 6 Alexander Larsson 2005-05-06 05:06:13 EDT
The reason they wanted to change the string was to get a different font size
though. Can't do that using fontconfig.
Comment 7 David Zeuthen 2005-05-06 15:26:41 EDT
OK, decisions, decisions... So, should I cook up a patch for disabling this such
that we always use Sans? Alex: Will upstream take this? If not, do we really
want to diverge from upstream?
Comment 8 Leon Ho 2005-05-08 22:32:51 EDT
Sounds good David. May I suggest as the fix is required on Fedora anyway, can we
patch our package first and propose this to upstream concurrently?
Comment 9 Alexander Larsson 2005-05-09 04:33:59 EDT
Given the needs of the author of the original patch i think the right solution
is to allow localisation of the font size, but not the font name. 

davidz: Could you take a shot at that?

llch: btw. I am upstream.

Comment 10 David Zeuthen 2005-05-09 17:47:44 EDT
In response to comment 9, since it's a gconf default key I'm not sure how we
would allow only localisation of size but not name without breaking the schema.
What did you have in mind, Alex?

What about just a) changing the translator comment and ask translators to not
change anything but the size?; and b) fixing up the translations as they are now?

Comment 11 Alexander Larsson 2005-05-10 04:34:33 EDT
Well, it is hard to do without changing the schema.
You'd do it by changing the default to "Sans", not translatable. Then you'd add
a new translated string (not in gconf) that sets the default font size. When
parsing the default font for the desktop, if the font size is not set
[pango_font_description_get_size() == 0] then you'd use that.

However, maybe your proposal is good enough. Its clearly less work and more
backwards compatible. Lets go with that.
Comment 12 David Zeuthen 2005-05-10 14:46:50 EDT
Created attachment 114216 [details]
Proposed patch

Alex: What about the attached patch? Leon: is "Sans 10" good enough for zh_TW?
Comment 13 David Zeuthen 2005-05-10 15:18:43 EDT
I've uploaded test packages here 


Leon, please give them a whirl. 

Comment 14 Alexander Larsson 2005-05-11 04:59:10 EDT
davidz: Looks good to me. Please commit on HEAD and gnome-2-10 branch.

Also, could you fix up po/gu.po which seems to also have translated this string.
Comment 15 David Zeuthen 2005-05-11 10:34:26 EDT
I've built nautilus-2.10.0-4 with this patch. It should be in Rawhide tomorrow.
I'll follow up on the upstream bug with a patch for HEAD and gnome-2-10.
Comment 16 Leon Ho 2005-05-11 21:13:39 EDT
Thanks, I have tested it on my system by following test case:

1. zh_TW.UTF-8 in /etc/sysconfig/i18n
2. Create a new user to make sure I haven't got any font customization.
3. Login with that user

Sans 10 is good for zh_TW.

Thanks for your work David.

Note You need to log in before you can comment on or make changes to this bug.