Problems with Turkish

Hi
Does anybody know if Turksih is supported by weblogic 8.1
I have a US windows weblogic 8.1 sp4 system which every time i set the regional settings to turkish i can't start weblogic
I get the following error:
The WebLogic Server did not start up properly.
Exception raised: 'weblogic.management.configuration.ConfigurationException: Exc
eption thrown in operation getMBeansFromURL - with nested exception:
[javax.management.ServiceNotFoundException: Problems while parsing URL file:/C:/
bea/user_projects/domains/mydomain/./myserver/load.mlet]'
Reason: weblogic.management.configuration.ConfigurationException: Exception thro
wn in operation getMBeansFromURL - with nested exception:
[javax.management.ServiceNotFoundException: Problems while parsing URL file:/C:/
bea/user_projects/domains/mydomain/./myserver/load.mlet]
When i revert the Regional settings to English everything works fine
Is their anything I can do..?
Thanks
Liam

Miriam,
What encoding are the TOC and index XML files being generated in? You should use UTF-8 for the minimum of problems. I presume WebWorks has an option for this. Other than that, make sure the top of those XML files has the proper XML declaration with the encoding:
<?xml version="1.0" encoding="UTF-8"?>You may want to try opening the XML files in an XML-aware text editor to ensure they look right there (JDeveloper is one such editor).
If all of that is working, post back and we can talk offline about getting a snippet of one of those XML files for us to look at.
-brian

Similar Messages

Drill problem with Turkish charecters

Hi all,
we've a problem with turkish charecters in drill mode.
Drill mechanism doesn't work when user select a data with turkish charecters, report show all data.
I need your helps
our system is BO 3.0 Edge Series

You can change the special chars with the UNICODE values of these chars.
For example:
name=name.replace(/�/g,"İ");
name=name.replace(/�/g,"Ş");
name=name.replace(/�/g,"Ğ");
End your queryString must be as follows:
queryString = "?name=" + escape(name) + ".........";

Problems with Turkish characters not displaying correctly

A user is having problems with certain Turkish characters in particular fonts not displaying correctly (as shown below).
The two fonts (Gill Sans and Helvetica LT CondensedLight) are used for English language marketing material. Ideally, for continuity, the same font would be preferred for our Turkish language marketing material rather than changing it to a similar font.
Helvetica LT CondensedLight
Turkish character “ İ ” does not display correctly in either Word or InDesign.
Gill Sans
Turkish characters “ ş ” and “ ğ ” display correctly in Word but not InDesign.
My questions are:
1. For Gill Sans, why are the characters not displaying in InDesign but are in Word?
2. I've noticed here: http://www.webtype.com/font/gill-sans-family/#glyphs-tab that the required characters are available within the Gill Sans font. Is this because the font is newer and includes the additional characters? Would this work in InDesign?

One of the big differences between InDesign and Word is that Word will happily substitute glyphs without telling you. So, unless your installs of Word and of InDesign are using different versions of Gill Sans (which is possible, BTW) then your s-with-cedilla and your g-with-macron are actually not in Gill Sans but in some other font. I'm guessing Arial.
It's possible that you have more than one Gill Sans installed (e.g. one in your Document Fonts folder and another in your system fonts folder) that have different glyph complements. Gill Sans has been around a long time, and the version I have from the 90s has no Turkish support whatsoever.
As far as the capital-I-with-dot, you can check your glyph coverage in a variety of ways. In both InDesign and Word, you can open up a window that shows you all of the glyphs in a font. In InDesign, find it in Type -> Glyphs. In Word, it's called "Insert Symbol" and you can find it in Word 2010 by going to Insert -> Symbol -> More Symbols. I am guessing that the answer to this question is simply that your cut of Helvetica LT has no cap-I-with-dot. You'd need to pick a font that actually has support for Turkish. On WIndows, I use a very full-featured freebie called BabelMap to check font coverage. They have a Web version here:
http://www.babelstone.co.uk/Unicode/babelmap.html
but I personally prefer the downloadable .exe file.

Problems with Turkish special characters

Hello!
We are producing Oracle Help with WebWorks Publisher 2003 Professional for FrameMaker. There are some problems with the Turkish version of our online help: The Turkish special characters (for example the dotless i) aren´t displayed correctly in the navigation panes TOC and index. They are replaced by other characters (for example by a "y")
Has anyone an idea how to solve this problem?
Thank you very much.
Kind regards,
Miriam Rassenhofer

Miriam,
What encoding are the TOC and index XML files being generated in? You should use UTF-8 for the minimum of problems. I presume WebWorks has an option for this. Other than that, make sure the top of those XML files has the proper XML declaration with the encoding:
<?xml version="1.0" encoding="UTF-8"?>You may want to try opening the XML files in an XML-aware text editor to ensure they look right there (JDeveloper is one such editor).
If all of that is working, post back and we can talk offline about getting a snippet of one of those XML files for us to look at.
-brian

Playlist Problem With Turkish Character Set (Windows-1254 or ISO 8859-9)

I'm using my x-fi 2 just for 2 week and sicked and tired it's problem. Now i have a problem with playlist. If my mp3 or m4a files or folder names have turkish character playlist's seems empty but i can find the files under albums and artist name sectors.
My question is the any way to solve this problem. Folder names is not problem but file names i can not change all of them. Please help.

meraba ankara yasiyorum.Sizinle mail araciliyla görüsmemiz mumkun mu?
e_mail: [email protected]
Bilgisayırıma 10g express edition yükledim .Bi de ODT for 10gXE (ADD-in) yükledim.Ama
connect e basınca veritabanına .net den baglanamıyorum username yada password yanlis diyor.string name express edition icin nedir..net 2003 bilgisayarima yüklü.
.net ve oracle kullanarak bir proje yapmak istiyorum.Yardimci olabilirmisiniz
saygilar..

Dreamweaver code view problem with Turkish fonts

All my preferences is set to Turkish encoding, but only at the code window Turkish characters aren't displayed right. If i type directly into the code window, everything is ok. but if i write something to design windowi the characters change automatically. i'm attaching a picture to show.
thanks in advance.

What you see there is not a problem. It's the expected result.
When the Web first started, it supported only unaccented characters. So, to create letters like ö, it was necessary to use HTML entities, which is what you see in Code view.
Nowadays, browsers support Unicode (UTF-8), which doesn't need to convert accented characters.
Go into Preferences (from the Edit menu on Windows, Dreamweaver window on a Mac), and select the New Document category. Set encoding to UTF-8. To change existing pages, use Modify > Page Properties, and select Title/Encoding.
With UTF-8, ö will still be ö in Code view.

Font problems with dreamweaver on Mac

Hi, i installed dreamweaver cs3 as a part of web premium
suite on intel mac os x 10.4.10. My international settings are set
to Turkish. There are some oddities with fonts. Dreamweaver font
list displays some fonts with CE suffix (Helvetica CE, Lucida
Grande CE ...) but these fonts are not installed on my computer.
How does dreamweaver displays these fonts? I checked the install
log and couldn't find where these fonts are located. Other
applications in the web premium package doesn't show these fonts.
Also, dreamweaver is having problems with Turkish characters
if I don't use these fonts. For example, I want to use default
operating system fonts Helvetica or Lucida Grande (which have
Turkish character support and works fine with Adobe Photoshop CS3
and Illustrator CS3) in css font family but Dreamweaver can not
display Turkish characters with these fonts. If I use Helvetica CE
instead of Helvetica, Turkish characters are displayed without any
problem but this is not an option because most people have
Helvetica (not Helvetica CE). Previously I was using Dreamweaver MX
2004 on windows and didn't have any problems with Turkish
characters.

Update,
I have this type of code in the old pages on my body text I'm guessing it's because in most of my pages i.e. old dreamweaver mx days I've selected the text and formatted with the property inspector instead of css by mistake.
text eh?

But I want them like this so i can change it all with css vs manually.
text eh?
So I've followed your advice and searched and replaced the former with the later on the dreamweaver template page and on a few individual pages, hoping that will allow me to eventually use css to adjust it all.
I am very very tempted to do a global search and replace with changing
this 
to this 
and this 
to this 
but I'm kinda worried if I don't do each page manually and test each one, all 148 pages, oh joy, and check something it could bork my site in ways i'll take forever to find out and fix. Am I correct in worrying about this?

Late 2013 Macbook Pro Retina with Turkish Q Keyboard, In windows 8.1 " and working inverse

I've late 2013 mb Pro with Turkish Q. I have installed windows 8.1 with bootcamp. But my buttons " and < working inverse. < button writes " and " writes <. If i use external apple q turkish keyboard no problem. In maverics evereything is ok. How can i solve?

Can I suggest the following articles, which are worth reviewing?
Boot Camp: About keyboards and key assignment for Microsoft Windows - Apple Support
Boot Camp: Apple Wireless Keyboard keyboard mapping in Windows - Apple Support
Boot Camp: Windows commands on an Apple keyboard
Windows does require language packs to be installed, if you want the physical keyboard to match the on-screen keyboard.

Problem with decimal in Japan currency

Hi Gurus,
I have a problem with Japan currency that when When i take the printout of document with JPY 5,168,277 it is wrongly printing as 51,682.77 but in document display it is showing correclty as 5,168,277. But when i check this in BSEG table it was wrong updated as 51,682.77 (WRBTR field) i hope it is picking the amount from this field for printing .
For the above i made changes in OY01 but i find there was no use.
In OY01 the decimal place setting is 1,234,567.89 the middle one of the three.
When i post the same amount to japan co code in currency JPY and if i check in BSEG table
Amount in LC                                      51,682.77
Amount          (WRBTR)                       51,682.77
Orig.reduction                                      0.00
G/L amount                                         5,168,277
When i post the same amount in non japan co code in JPY Currency and check in BSEG(area where i am facing problem)
Amount in LC                                      47,550.22
Amount          (WRBTR)                       51,682.77
Orig.reduction                                      0.00
G/L amount                                         5,168,277
Please tell me how to correct this.

May ne u can check this OSS note also 137626
Summary
Symptom
1. Which currencies have to be defined separately with regard to the number of decimal places?
2. What do I need to observe when maintaining decimal places for currencies?
3. Which Customizing presettings does SAP deliver in table TCURX (decimal places for currency codes)?
4. Does SAP deliver the Customizing presettings of decimal places for currency codes (Table TCURX) for upgrade installations?
5. Which information does SAP use for the specification of these Customizing presettings?
Solution
1. question: Which currencies have to be defined separately with
            regard to the number of decimal places?
Answer:
The number of decimal places can vary for currencies. Currencies which do not have two decimal places must be defined in table TCURX (decimal places for currency codes).
You can maintain this table via the R/3 Implementation Guide (Global Settings -> Currencies, Transaction OY04).
If a currency is not defined in Table TCURX (decimal places for currency codes), this currency is regarded as currency with two decimal places.
2. question: What do I need to observe when maintaining decimal places
            for currencies?
Answer:
During operation, you must neither delete currencies used nor change their definition of decimal places. Amounts in posted documents could become invalid or incorrect as a result.
3. question: Which Customizing presettings does SAP deliver in table
            TCURX (decimal places for currency codes) ?
Answer
At present, SAP delivers the following Customizing presettings for table TCURX:
ISO Currency Decimal places
Code
ADP   Andoran Peseta                            0
AFA   Afghani Afghani                          0
BEF   Belgian franc                             0
BHD   Bahraini dinar                            3
BIF   Burundi franc                             0
BYB   Belorussian rubel (old)                   0
BYR   Belorussian rubel (new)                   0
CLP   Chilean peso                              0
COP   Columbian peso                            0
DEM3 (Internal) German Mark (3 Dec.)           3
DJF   Djibouti franc                            0
ECS   Ecuadorian sucre                          0
ESP   Spanish peseta                            0
GNF   Guinea franc                              0
GRD   Greek drachma                             0
HUF   Hungarian forint                          0
IDR   Indonesian rupiah                         0
IQD   Iraqui dinar                              3
ITL   Italian lira                              0
JOD   Jordan dinar                              3
JPY   Japanese yen                              0
KMF   Comoros franc                             0
KRW   South Korean won                          0
KWD   Kuwaiti dinar                             3
LAK   Laos new kip                              0
LUF   Luxembourg franc                          0
LYD   Libyan dinar                              3
MGF   Madagascan franc                          0
MZM   Mozambique metical                        0
OMR   Omani rial                                3
PTE   Portugese escudo                          0
PYG   Paraguay guarani                          0
ROL   Roumanian Lei                             0
RWF   Rwanda franc                              0
TJR   Tadzhikistani rubel                       0
TMM   Turkmenistani manat                       0
TND   Tunesian dinar                            3
TPE   Timor escudo                              0
TRL   Turkish lira                              0
TWD   New Taiwan dollar                         0
UGX   Uganda shilling                           0
USDN (Internal) US Dollar (5 dec.pl.)          5
VND   Vietnamese dong                           0
VUV   Vanuata vatu                              0
XAF   CFA Franc BEAC                            0
XOF   CFA Franc BCEAO                           0
XPF   CFP Franc                                 0
4. question: Does SAP deliver the Customizing presettings of decimal
            places for currency codes (Table TCURX) for upgrade
             installations?
Antwort
Table TCURX (decimal places for currency codes) is a client-independent table of the delivery class "C" (Customizing table). Therefore the table contents for this table can only be delivered with new installations.
For upgrade installations, new or changed contents of Table TCURX are not delivered.
5. question: Which information does SAP use for the specification of
             these Customizing presettings?
Answer
Currency codes and decimal places for currency codes are defined in ISO standard 4217. For the specification of decimal places for currency codes, SAP uses this ISO standard.
For some currencies, for example, for the "Turkish lira", the decimal places which are used in reality deviate from the ISO definition. In many of these cases, SAP decided to adhere to the definitions generally used.
Example:
ISO standard 4217 defines two decimal places for the Turkish lira (TRL), however in reality zero decimal places are being used for the Turkish lira. SAP delivers zero decimal places as Customizing presetting for "Turkish lira".
Header Data
Release Status: Released for Customer
Released on: 14.08.2007 13:12:09
Priority: Recommendations/additional info
Category: FAQ
Primary Component: XX-CSC-XX Country specific Customizing & Functionality (Standard R/3)
Secondary Components: FI Financial Accounting
Releases
Release Independant
Related Notes
434349 - Change of decimal places of currencies
126531 - Collective note preliminary availability Colombia
Print Selected Notes (PDF)

Problem with the Non-English Characters

Hello,
I have been using Adobe Illustrator but I have a huge problem with the non-english characters with Standart Fonts. With the Professional font's I have no problem with them. But when I'm using any standart font in font folio library I cannot type any "ğ-İ-ş". I can add those letters in fontlab with the glyphs (scedilla, idotaccent, gbreve). Most of the fonts have those letters already prepeared so I dont even have to redraw. But I can't add those glyph to every single font because I dont have that kind of time and patience. Is there any better solution for this? Or is there any font folio pack that all fonts are PRO.
I'm looking forward for your answers
Thanks.

Joel wrote: I'm told that this is the exact difference between Adobe's Standard and Pro fonts — the Pro fonts have additional glyphs, including those necessary for extended Latin script.
Exactly. The Pro fonts have at a minimum the Adobe Western 3 character set, which is essentially western European + Adobe CE.
> Standard fonts just have the basic English character set, with maybe a bit of help for Spanish and French.
A lot more than that!
> You're doing Turkish, right? Adobe's coverage for Turkish in its fonts is not great - some of the Pro fonts have Turkish coverage, many do not.
This is false. Every single Adobe Pro font supports Turkish.
To be clear:
All Adobe Standard fonts support the following languages: Afrikaans, Basque, Breton, Catalan, Danish, Dutch, English, Finnish, French, Gaelic, German, Icelandic, Indonesian, Irish, Italian, Norwegian, Portuguese, Sami, Spanish, Swahili and Swedish.
Adobe Pro fonts support those languages, plus AT LEAST: Croatian, Czech, Estonian, Hungarian, Latvian, Lithuanian, Polish, Romanian, Serbian (Latin), Slovak, Slovenian and Turkish. Some Pro fonts have more language support than this, such as Greek and/or Cyrillic, and additional extended Latin.
See: http://www.adobe.com/type/browser/info/charsets.html
Cheers,
T

Can I use Ipad2 3G in Turkey with Turkish gsm?

Can I use Ipad2 3G in Turkey with Turkish gsm?

If you have a GSM iPad 3G and you can find a Turkish carrier that offers an iPad data plan, you should have no problems.
Regards.

Problem with currency fields

Hi,
My international settings are set to Turkish locale. I created a spreadsheet and defined a column as currency. Turkish currency symbol is YTL. When I want to make calculations using cells on that column, I get "+The operator "*" expects a number but the cell contains string+" error. Numbers doesn't understand that YTL is the currency symbol and prohibits any calculation. If I change the locale to U.S.A, and define the same column as currency, i can make calculations on this column. Does anyone has the same problem with different locale?
Thanks
Bilgehan

Hello
Glad to give you the ability to work flawlessly.
I will report to Apple because the behaviour is really foolish.
If I enter System Prefs to select Turkish as used language, the currency is displayed as
If with this setting I enter Numbers, type 123 and apply the currency format, the cell displays
TRY is the official ISO 4217 symbol but it's not the system setting and it is not treated as a currency symbol so the cell is treated as a string.
If I enter the Inspector and select "livre turque (TL)"
the cell is treated as a number.
Funny isn't it.
Yvan KOENIG (from FRANCE vendredi 8 février 2008 14:33:53)

Bug with TURKISH local

hi ,
I have dowloaded odp.net and I was looking at samples , but there are some problems guys.These are :
my connection string in sample is
string constr = "User id=scott;Password=TIGER;Data Source=honest";
"User Id=" doesn't work gives error , but "User id=" works
and also
"password=tiger" doesn't work , but "password=TIGER" works.
I think there is some problems with "I" character because in turkish language i and I are different letters.

What is the error message and the call stack of the exception?

Problem with Reports & Graphics in PDF

Hi,
I generated a report into PDF file which contain layout for Line
Graph, but I can't get multiple colour of line for columns value.
I also have same problem with Pie Chart.Please give me some
advice.
Thanks in advance.
null

A month ago I have a problem with my pdf output because of TURKISH Characters. I applied this method as you can see below for solve this problem...
1. Go under the following path: $COMMON_TOP/util/java/1.4/j2sdk1.4.2_04/jre/lib/fonts
2. Copy all the ttf font files under <FND_TOP>/<APPLRSC>/ to that path
3. Bouns the Concurrent Manager and the Apache Server
4. Retest the issue.
5. Migrate the solution as appropriate to other environments.

Upgarded Oracle database works incorrect with Turkish Characters

Hi All,
I have upgarded my database from oracle version 7.3 to 8.0.6.
My new database in oracle 8.0.6 works incorrect with Turkish Characters, displays incorrect.
I tried creating new oracle database in oracle 8.0.6, not upgrading as above, this database works well with Turkish Characters.
Please help me to fix above problem in my upgraded database.
Thanks in advance.
Thuong Tran.
null

Use Ariel MS Unicode font.

Problems with Turkish

Similar Messages

Maybe you are looking for