| Key: |
VWR-1742
|
| Type: |
Bug
|
| Status: |
Resolved
|
| Resolution: |
Needs More Info
|
| Priority: |
Major
|
| Assignee: |
Unassigned
|
| Reporter: |
Vixen Heron
|
| Votes: |
0
|
| Watchers: |
2
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
File Attachments:
|
None
|
|
Image Attachments:
|
|
|
Environment:
|
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600) (Turkish Version)
|
|
Issue Links:
|
Relates
|
|
|
|
This issue is related to by:
|
|
VWR-5110
Localization problem (utf-8 does not work properly, need iso-8859-2 enable)
|
|
|
|
|
|
VWR-1719 Need for a better mechanism to add new UI translation
|
|
|
|
|
|
|
| Linden Lab Issue ID: |
SL-50140
|
|
Hello,
I'm working for translation the viewer into Turkish language on recent days.
Actually problems which can be seen on screenshots effect my works.
As you see,three characters don't seem bold like the others.(These are for chat typings)
If i can't use the letters which are shown with red dots above them(to see clearly),then i shouldn't use "ç", "ö" and "ü" also.(It's impossible to use on menus already)
I can complete my translation without using these ones,then it won't be totally Turkish but will able to be read by Turkish people.
Another little thing is on my German language screenshot,some typings owerflow on the box or out of the box(This example doesn't mean that i dislike Germany etc.So please don't get angry with me.)
What i need to do about this?
I can fix via changing widht of boxes etc,i hope this doesn't effect the standart of the viewer.
Last wonder is,i see from translation files that lots of parts of the viewer can be changed but they weren't completely translated on other languages.For example while teleporting from one location to another,the system messages as "Connecting,Teleporting,Arriving" are the default game words at English.So are they like this because of their beta situation or aren't we allowed to translate?
I'll be glad with your comments and solutions about these issues,so i can go on my translation project better.
Thank you very much.
|
|
Description
|
Hello,
I'm working for translation the viewer into Turkish language on recent days.
Actually problems which can be seen on screenshots effect my works.
As you see,three characters don't seem bold like the others.(These are for chat typings)
If i can't use the letters which are shown with red dots above them(to see clearly),then i shouldn't use "ç", "ö" and "ü" also.(It's impossible to use on menus already)
I can complete my translation without using these ones,then it won't be totally Turkish but will able to be read by Turkish people.
Another little thing is on my German language screenshot,some typings owerflow on the box or out of the box(This example doesn't mean that i dislike Germany etc.So please don't get angry with me.)
What i need to do about this?
I can fix via changing widht of boxes etc,i hope this doesn't effect the standart of the viewer.
Last wonder is,i see from translation files that lots of parts of the viewer can be changed but they weren't completely translated on other languages.For example while teleporting from one location to another,the system messages as "Connecting,Teleporting,Arriving" are the default game words at English.So are they like this because of their beta situation or aren't we allowed to translate?
I'll be glad with your comments and solutions about these issues,so i can go on my translation project better.
Thank you very much. |
Show » |
|
Unicode problem when using Turkish alphabet characters in viewer.
As far as I understand, Turkish requires several hooked characters, several characters with diaeresis, a soft G, and distinction of dotted and dottless I. In your figures, I see uses of C with hook, S with hook, O with diaeresis, U with diaeresis, soft G, and dotted and dotless I, as well as ASCII letters. Very interesting. Are they all you need to write Turkish?
Random thoughts on this issue follow:
(1) The reason characters not in latin-1 doesn't be bolded is in the way SL viewer handles fonts. At this moment, SL viewer come with its own fonts (MetaBook and its bold counterpart BetaBold) that only contain Latin-1 characters. SL viewer handled other characters than Latin-1 with fallback mechanism, and in fallback fonts, it doesn't differentiate normal and bold. As a result, your non Latin-1 characters, e.g., S with hook, are always rendered as a normal (no bold).
(2) It is not hard to rewrite font handling code to distinguish normal and bold faces even on fallback ones, but if we do so, we face another problem. Not all fonts come in normal and bold variants. Turkish only require Latin letters, and it is easy to find normal/bold paired fonts. However, Japanese (that's my native tangue...) font rarely come with normal/bold pair. I believe there are some other scripts, e.g., Korean Hangul, Indic Divanagari, or Hebrew have same situation.
(3) This discussion goes into yet another question; Why SL viewer come with such poor font files? Well, I'm not saying SL viewer supplies righ font file (it is technically easy, but LL needs to pay huge amounts of money to do so...) My question is why SL viewer requires its own MetaBook/MetaBold font files? Just using OS supplied fonts seems better, considering the fact that modern OS come with a set of fonts that cover a large amount of scripts, and for alphabetic scripts (e.g., Latin, Greek, Cyrillic) they come with normal/bold pair.
(4) Just support Turkish in Chat text is OK. However, if we allow Turkish named objects, we may have a trouble. Turkish has dotted and dotless I as distinct lettters. Both of them have upper and lower cases. In English, upper case I is dotless and lower case I is dotted. In SL, object name matching is usually done in case insensitive manner, and in the current version, the case folding is always done in English way, i.e., an upper case counterpart of a dotted small I is the dotless capical I... On the other hand, if we introduce locale sensitive case folding, the object name matching behave differently on English speaking users and on Turkish speaking users. I know this issue occurs in a future but did not think this soon...
BTW, as a short term hack, you can test your translation by adding the following two lines in your settings.xml file:
<FontSansSerif value="TAHOMA.TTF" />
<FontSansSerifBold value="TAHOMABD.TTF" />
This settings instructs SL viewer to use Windows' standard Tahoma font (that of course includes all Turkish letters) instead of SL viewer's MonoBook fonts everywhere in the viewer display. Have fun!