Bug 154185 - nautilus is pulling in AR PL KaitiM font for zh_TW
Summary: nautilus is pulling in AR PL KaitiM font for zh_TW
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: nautilus
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC4Target
TreeView+ depends on / blocked
 
Reported: 2005-04-08 01:22 UTC by Leon Ho
Modified: 2013-03-06 03:43 UTC (History)
3 users (show)

Fixed In Version: 2.10.0-4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-11 14:34:26 UTC
Type: ---
Embargoed:


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

Description Leon Ho 2005-04-08 01:22:13 UTC
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
3.
  
Actual results:
KaitiM is used

Expected results:
Mingti should be used

Additional info:

Comment 1 Akira TAGOH 2005-04-12 06:12:54 UTC
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 15:36:42 UTC
I'm not sure why upstream did this. Do you know, Alex?

Comment 4 Alexander Larsson 2005-05-04 08:16:46 UTC
Here is the upstream bug that initiated the change:

http://bugzilla.gnome.org/show_bug.cgi?id=138731

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-05 01:24:55 UTC
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 09:06:13 UTC
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 19:26:41 UTC
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-09 02:32:51 UTC
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 08:33:59 UTC
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 21:47:44 UTC
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?

David

Comment 11 Alexander Larsson 2005-05-10 08:34:33 UTC
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 18:46:50 UTC
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 19:18:43 UTC
I've uploaded test packages here 

 http://people.redhat.com/davidz/bug154185/

Leon, please give them a whirl. 

Thanks,
David

Comment 14 Alexander Larsson 2005-05-11 08:59:10 UTC
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 14:34:26 UTC
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-12 01:13:39 UTC
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.