KDE (or GNOME?) non-latin chars input problem

After recent upgrade (pacman -Syu) can't anymore type non-latin characters in GNOME apps (like gEdit, Evolution, Thunderbird etc.) under KDE. Openoffice is still OK.
Keyboard layout switching works (can see the difference between US and GB layouts, but when switching to non-latin layouts getting latin chars instead of non-latin.
In KDE apps everything is fine.
Have current KDE and GNOME installed.
BTW, when trying to run Epiphany web browser (under KDE again) getting error message (not sure but maybe this is related to the first problem):
"Could not start GNOME Web Browser
Startup failed because of the following error:
Unable to determine the address of the message bus (try 'man
dbus-launch' and 'man dbus-daemon' for help)"
Have dbus in DAEMONS line in rc.conf.
Any suggestions?

Fixed first problem... rollback of inputproto and libxi did the trick (not sure how safe it was).
scarecrow, thank you for your reply but it didn't help for the second problem. Changed DAEMONS to hal only, added dbus-python and even dbus-sharp (just in case, all other dbus related stuff was already there) but - no luck. Perhaps dbus-1.0 might be a solution who knows.
Thanks anyway.

Similar Messages

[Solved]Ctrl+V not working in libreoffice on gnome(non-latin layout)

When using gnome-shell&libreoffice or calligra, universal keyboard shortcuts such as ctrl+v or ctrl+z don't do anything while on a non-latin layout(hebrew in my case).
If I want to paste something with ctrl+v I have to change layout to English and only then will it work.
Under MATE the shortcuts work fine regardless of the layout in both applications(and all others i have tried).
Under GNOME Shell all other applications I tried accept the shortcuts regardless of the layout(Firefox, gedit, Empathy, Nautilus)
Anyone has an idea as to what might cause this behavior when using GNOME?
Thanks.
EDIT: Solved for libreoffice by removing the package "libreoffice-gnome". UI is not as pretty now but at least the keyboard shortcuts work.
Last edited by shimi (2013-08-09 09:00:50)

After months of switching layouts and banging my head against this bug, I thought I should check LibreOffice settings (I'm using 4.1.5.3 now). What figures? I did find something. And in just a few clicks.
This is not a bug! It's simply a matter of configuration.
For the regular keyboard shortcuts (like Ctrl+C, Ctrl+V, etc.) to remain operational in LibreOffice applications while using a non-latin keyboard layout (like Greek or Russian), go to Tools -> Options -> Language Settings -> Languages, check the Ignore system input language option, save, and Bob's your uncle.
Hope this helps.
Cheers!
PS
Technically, though, shortcuts still remain language-dependent. This means if you enable this option, you will have to set your document languages manually.

IReport and non latin chars

When printing through iReport with russian chars, it prints corrent but when converting the same file to PDF or HTML etc., it converts only latin chars but not russian.
Does anyone knows what is wrong?

i think this is not the right forum to ask such questions...
you should ask from the producers of IReport (this is not their website!)
and when you go asking that, then also provide more information about your problem, for example which OS you're running that product on etc.
maybe it's some problem with lack of font support... maybe it's problem with your PDF viewer, i don't know... but i know whose fault that is noh, it is not my fault!

Regex with strings that contain non-latin chars

I am having difficulty with a regex when testing for words that contain non-latin characters (specifcally Japanese, I haven't tested other scripts).
My code:
keyword = StringUtil.trim(keyword);
//if(keywords.indexOf(keyword) == -1)
regex = new RegExp("\\b"+keyword+"\\s*;","i");
if(!regex.test(keywords))
{Alert.show('"'+keywords+'" does not contain "'+keyword+'"'); keywords += keyword + "; ";}
Where keyword is
日本国
and keywords is
Chion-in; 知恩院; Lily Pond; Bridge; 納骨堂; Nōkotsu-dō; Asia; Japan; 日本国; Nihon-koku; Kansai region; 関西地方; Kansai-chihō; Kyoto Prefecture; 京都府; Kyōto-fu; Kyoto; Higashiyama-ku; 東山区; Places;
When the function is run, it will alert that keywords does not contain keyword, even though it does:
"Chion-in; 知恩院; Lily Pond; Bridge; 納骨堂; Nōkotsu-dō; Asia; Japan; 日本国; Nihon-koku; Kansai region; 関西地方; Kansai-chihō; Kyoto Prefecture; 京都府; Kyōto-fu; Kyoto; Higashiyama-ku; 東山区; Places; " does not contain "日本国"
Previously I was using indexOf, which doesn't have this problem, but I can't use that since it doesn't match the whole word.
Is this a problem with my regex, is there a modifier I need to add to enable unicode support or something?
Thanks
Dave

ogre11 wrote:
> I need to use refind to deal with strings containing
accented characters like
> ?itt? l?su, but it doesn't seem to find them. Also when
using it with cyrillic
> characters , it won't find individual characters, but if
I test for [\w] it'll
> work.
works fine for me using unicode data:
<cfprocessingdirective pageencoding="utf-8">
<cfscript>
t="TÃ¡ mÃ© in ann gloine a ithe;
NÃ chuireann sÃ© isteach nÃ³ amach
orm";
s="Ã¡";
writeoutput("search:=#t#<br>for:=#s#<br>found
at:=#reFind(s,t,1,false)#");
</cfscript>
what's the encoding for your data?

Non-english characters input problem on remote device

Hello.
I have ZCM 11 SP1. In remote management I can input on remote device only English characters.
When I change keyboard layuot to Russian - no input at all. But I need Russian keyboard working. Help, please.
Management device is Windows XP SP3 box, admin device - Windows 7 SP1 and Windows XP SP3 boxes

9113060,
> I have ZCM 11 SP1. In remote management I can input on remote device
> only English characters.
> When I change keyboard layuot to Russian - no input at all. But I need
> Russian keyboard working. Help, please.
>
> Management device is Windows XP SP3 box, admin device - Windows 7 SP1
> and Windows XP SP3 boxes
Need more info here. I just tested it on Swedish and it works just fine,
but when you say "When I change keyboard layuot to Russian" does that
mean that the default on your machine or the target machine is not
Russian?
- Anders Gustafsson (NKP)
The Aaland Islands (N60 E20)
Novell has a new enhancement request system,
or what is now known as the requirement portal.
If customers would like to give input in the upcoming
releases of Novell products then they should go to
http://www.novell.com/rms

Hot Sync with Non-latin Character Display Problem

I have a XP Home Desktop with Palm Desktop 4.01 installed. When I do a hot sync with my Sony Clie T655C, the chinese characters are display correctly in both XP home Desktop and the Clie.
Now, I have a netbook with window7 Starter installed for travelling use. It took me a while to resolve the problem on the hotsync with window 7 starter and sony clie. At the end, I have Palm desktop v6.2 and Palmhotsyncsetup from pimlico on the netbook. I am able to do a hotsync with cradle/cable, but not through network (with TCP/IP not listen error message).
I have installed the chinese, English, french IME for the window 7 Starter netbook. I am able to type Chinese character in Notepad and Word and display the character correctly. I am able to save the file ( filename in both chinese and english character), re-open it and all characters are displayed correctly.
But with Palm Desktop v6.2, I am able to type chinese and the characters are displayed correctly in calendar/data book. When I close the palm desktop and re-open it again. All the characters become "?", as a result, I can not fully evaluate the software Pimlico for window desktop. As it only works with Palm desktop v6.2.
Any suggestion?
Post relates to: Palm TX

I have a XP Home Desktop with Palm Desktop 4.01 installed. When I do a hot sync with my Sony Clie T655C, the chinese characters are display correctly in both XP home Desktop and the Clie.
Now, I have a netbook with window7 Starter installed for travelling use. It took me a while to resolve the problem on the hotsync with window 7 starter and sony clie. At the end, I have Palm desktop v6.2 and Palmhotsyncsetup from pimlico on the netbook. I am able to do a hotsync with cradle/cable, but not through network (with TCP/IP not listen error message).
I have installed the chinese, English, french IME for the window 7 Starter netbook. I am able to type Chinese character in Notepad and Word and display the character correctly. I am able to save the file ( filename in both chinese and english character), re-open it and all characters are displayed correctly.
But with Palm Desktop v6.2, I am able to type chinese and the characters are displayed correctly in calendar/data book. When I close the palm desktop and re-open it again. All the characters become "?", as a result, I can not fully evaluate the software Pimlico for window desktop. As it only works with Palm desktop v6.2.
Any suggestion?
Post relates to: Palm TX

Quastion marks in non-latin charecters when searching with google

Hello,
After installing firefox I encountered a problem.
I am on the hebrew version of the browser, updated to the latest (33.1) version.
When searching in the search bar with google using non-latin chars (hebrew) I am taken to google search page but instead of the search term I am getting quastion marks symbols (???????) I then need to again write the search term (which is now ok)
This doesn't happen in DuckDuckGo or Yahoo search.
A solution would be appreciated (and also important for other users)
Thank you

I can't seem to duplicate this. Are you typing in the same place I am?　I see I only have 6.0.1...

[SOLVED] Non english chars kdemod 4 problem

Hello, I have a little problem with KDE and the non english charactes.
If I open a file with non english chars in its name I get something like this:
(In this case kwrite opens "other" file but in other applications it fails with an error of file not found)
Other sympton is that in KDE menu my name have bad chars too:
(It must be López)
And the third sympton is that if try to rename a file in the desktop, I can't write accented chars (á é í ó ú). At the begining the keyboard in this rename dialog was totally in english but i have got a semi spanish keyboard (i can write ñ letters) with the apropiate /etc/hal/fdi/policy/10-keymap.fdi file.
But the most strange is that in general, in all Kde and non-kde applications and even in the console, non english chars works ok. I can go to the file->Open menu of the application and open a file with non english chars in its name. The problem seems to reside in the part of kde that passes the name of the file to the application (¿kwin?)
my locale is es_ES@UTF8 and as I said I have configured correctly the 10-keymap.fdi file.
I have read in some forums that something like this could be a kde or qt bug, but for me it's not clear as i don't see a general complaining about this.
Any idea will be apreciated.
Thanks in advance,
Christian.
Last edited by christian (2009-03-27 14:52:17)

SanskritFritz wrote:
That should be "es_ES.utf8"
Sorry, i mispelled it in the post.
Of course, my locale is es_ES.utf8:
LANG=es_ES.utf8
LC_CTYPE="es_ES.utf8"
LC_NUMERIC="es_ES.utf8"
LC_TIME="es_ES.utf8"
LC_COLLATE=C
LC_MONETARY="es_ES.utf8"
LC_MESSAGES="es_ES.utf8"
LC_PAPER="es_ES.utf8"
LC_NAME="es_ES.utf8"
LC_ADDRESS="es_ES.utf8"
LC_TELEPHONE="es_ES.utf8"
LC_MEASUREMENT="es_ES.utf8"
LC_IDENTIFICATION="es_ES.utf8"
LC_ALL=
I don't think this could be the source of the problem, because, except in the places I said in the firs post, the rest of my system works perfectly.

KDE, HAL, cannot open the non-latin mount point

I just installed ArchLinux for a few days and there is a problem here: I use KDE and hal, USB disk and CDROM can be auto-mounted. But if the USB Disk lable or CDROM label is non-latin characters, KDE, actually, Konqueror cannot open that mount point.
I think my charset is correct because in konqueror, the directory name of the mount point is correct. When I try to open this directory, konqueror complained that she cannot open that directory and the directory name which the error message dialog shows is wrong.
Any ideas? Thanks a lot.

kartwall wrote:
Problem solved -- modify the HAL mount point, so HAL will not use disk's lable to create a directory as mount point. Although this is not a perfect solution, but it works.
http://mail.kde.org/pipermail/kde-fr...il/000545.html
I think this is the page:
http://mail.kde.org/pipermail/kde-freeb … 00545.html
http://www.centos.org/modules/newbb/pri … SC&start=0
fifth and sixth post

Non- Latin characters not available following iCloud problem

Following help from HKQ recovering my Reminders (it turned out there was a problem with iCloud), my non-Latin characters (and the little globe icon for them have just vanished !) This must have happened during the reset or switching on iCloud. I need this really urgently to send emails to people. Please help,
thank you !

it's ok I found and added foreign keyboard. But the numbers give $ instead of £ even though it says it's on UK English,

BUG?? UTF-8 non-Latin database chars in IR csv export file not export right

Hello,
i have this issue: my database character set is UTF-8 (AL32UTF8) and contains data in a table used in IR that are Greek (non-Latin). While i can see them displayed correctly in IR and also via select / in Object Browser in SQL Workshop when i try to Download as csv the produced csv does not have the Greek characters exported correctly, while the Latin ones are ok.
This problem is the same if i try IE or Firefox. Also the export in HTML works successfully and i see the Greek characters there correctly!
Is there any issue with UTF-8 and non-Latin characters in export to csv from IRs ? Can someone confirm this, or has a similar export problem with UTF-8 DB and non-Latin characters ?
How could i solve this issue ?
TIA

Hello Joel,
thanks for taking the time to answer to my Issue. Well this does not work for my case as the source of data (Database character set) is UTF-8. The Data inside the database that are shown in the IR on the Screen is UTF-8 and this is done correctly. You can see this in my example. The actual Data in the Database are from multiple languages, English, Greek, German, Bulgarian etc that's why i selected the UTF-8 character set when implementing the Database and this requirement was for all character data. Also the suggested character set from Oracle is Unicode when you create a Database and you have to support data from multiple languages.
What is the requirement, is that what i see in the IR (i mean in Display) i need to export in CSV file correctly and this is what i expect from the Download as CSV feature to achieve. I understand that you had in mind Excel when implementing this feature but a CSV is just an easy way to export the Data - a Comma Separated Values file, not necessarily to open them directly in Excel. Also i want to add here that in Excel you can import the Data in UTF-8 encoding when importing from CSV, which is fine for my customer. Also Excel 2008 and later understands a UTF-8 CSV file if you have placed the UTF-8 BOM character at the start of the file (well, it drops you to the wizzard, but it's almost the same as importing).
Since the feature you describe and if i understood correctly is creating always an ANSI encoded file in every case, even when the Database character set is UTF-8, it is impossible to export correctly if i have data that are neither in Latin, not in the other 128 country specific characters i choose in Globalization attributes and these data is that i see in Display and need to export to CSV. I believe that this feature in case the Database character set is UTF-8 should create a CSV file that is UTF-8 encoded and export correctly what i see i the screen and i suspect that others would also expect this behaviour. Or at least you can allow/implement(?) this behaviour when Automatic CSV encoding is set to No. But i stongly believe - and especially from the eyes of a user - to have different things in screen and in the depicted CSV file is a bug, not a feature.
I would like to have comments on this from other people here too.
Dionyssis

Non latin characters in Safari search

In Safari 6 the search and URL fields are combined. That's fine, except...
We can no longer search using non-Latin characters, because the field accepts only Latin characters. I was trying to search for a Japanese term, and when I switch to Hiragana input and move to the search field, the input switches back to English.
What's the workaround??

The problem has gone away. I suspect it was a problem with corrupted prefs. I trashed the Safari prefs and rebooted to clear another problem and no longer have the problem with search using Japanese characters.
FWIW, the problem I had when I trashed the prefs was with trying to mail a Safari page. I ran in to this originally a week or two ago and called Apple who told me to delete the Safari prefs and reboot. (Actually they gave an alternate procedure to try first, but I didn't bother.) That appears to be a recurrent problem and since there was no hesitation on the solution when I called I would guess that it will be fixed in an early patch. I had already tried trashing the mail prefs since that's where the problem actually appeared (an extra copy of Mail would open, and then hang) but it was in fact the Safari prefs that was causing the problem. I've had to do the delete-and-reboot routine every few days. Not sure why the reboot is required, but it obviously is since just quitting Safari or even logging out doesn't fix it.

Cannot create file with Non-latin characters- I/O

I'm trying to create a file w/ Greek (or any other non-latin) characters ... for use in a RegEx demo.
I can't seem to create the characters. I'm thinking I'm doing something wrong w/ IO.
The code follows. Any insight would be appreciated. - Thanks
import java.util.regex.*;
import java.io.*;
public class GreekChars{
     public static void main(String [ ] args ) throws Exception{
          int c;
          createInputFile();
//          String input = new BufferedReader(new FileReader("GreekChars.txt")).readLine();
//          System.out.println(input);
          FileReader fr = new FileReader("GreekChars.txt");
          while( (c = fr.read()) != -1)
               System.out.println( (char)c );
     public static void createInputFile() throws Exception {
          PrintStream ps = new PrintStream(new FileOutputStream("GreekChars.txt"));
          ps.println("\u03A9\u0398\u03A0\u03A3"); // omega,theta,pi,sigma
          System.out.println("\u03A9\u0398\u03A0\u03A3"); // omega,theta,pi,sigma
          ps.flush();
          ps.close();
          FileWriter fw = new FileWriter("GreekChars.txt");
          fw.write("\u03A9\u0398\u03A0\u03A3",0,4);
          fw.flush();
          fw.close();
// using a printstream to create file ... and BufferedReader to read
C:> java GreekChars
// using a Filewriter to create files .. and FileReader to read
C:> java GreekChars
*/

Construct your file writer using a unicode format. If
you don't then the file is written using the platform
"default" format -probably ascii.
example:
FileWriter fw = new FileWriter("GreekChars.txt",
"UTF-8");I don't know what version of FileWriter you are using, but not that I know of take two string parameters. You should try checking the API before trying to help someone, instead of just making things up.
To the OP:
The proper way to produce a file in UTF-8 format would be this:
OutputStreamWriter writer = new OutputStreamWriter(new FileOutputStream("filename"), "UTF-8");Then to read the file, you would use:
InputStreamReader reader = new InputStreamReader(new FileInputStream("filename"), "UTF-8");

Non-Latin Character Display

I have several Java web applications on Tomcat where non-Latin characters function properly with only one exception. Non-Latin characters, Chinese in this case, can be displayed properly thorough the JSTL message tag. The related configuration are followings:
HTML: <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
JSP: <%@ page contentType="text/html;charset=UTF-8" language="java" %>
The applications can take Chinese character inputs correctly with a filter of converting request character encoding to "UTF-8".
The only problem is that Chinese characters don't displayed properly when they are directly typied on a JSP file. I have set the Eclipse file text encoding to utf-8 and the characters are shown correctly in the IDE.
I believe that is a TC configuration related issue. After having "set JAVA_OPTS= -Dfile.encoding=UTF-8" in the catalina.bat file, nothing has changed.
How to solve this problem?
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Solved!
Just need to have the JSP page tag on the related JSP file.
Message was edited by:
vwuvancouver

I have several Java web applications on Tomcat where non-Latin characters function properly with only one exception. Non-Latin characters, Chinese in this case, can be displayed properly thorough the JSTL message tag. The related configuration are followings:
HTML: <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
JSP: <%@ page contentType="text/html;charset=UTF-8" language="java" %>
The applications can take Chinese character inputs correctly with a filter of converting request character encoding to "UTF-8".
The only problem is that Chinese characters don't displayed properly when they are directly typied on a JSP file. I have set the Eclipse file text encoding to utf-8 and the characters are shown correctly in the IDE.
I believe that is a TC configuration related issue. After having "set JAVA_OPTS= -Dfile.encoding=UTF-8" in the catalina.bat file, nothing has changed.
How to solve this problem?
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Solved!
Just need to have the JSP page tag on the related JSP file.
Message was edited by:
vwuvancouver

Non-latin utf-8 characters on ssh host displayed as "???" in terminal

Both the client and the host use the same locale: en_US.UTF-8
I can input non-latin just fine but the resulting string appears in the terminal as question marks (e.g. "touch 表示してくれ; ls" gives me "??????????????????"), however if I check the same string with my SFTP client (Filezilla), the strings appears as intended so the character encoding seems to be handled correctly.
I'm using "gnome-terminal" on my client, in case that makes any difference (terminal parameters: on the client: TERM="xterm" and COLORTERM="gnome-terminal"; on the host: TERM="xterm").
Also, am I correct in assuming that I don't need to have any fonts installed on the host, as that's irrelevant to ssh?
UPDATE: I noticed a "cat" on a utf-8 text file on the ssh host shows the characters correctly, but looking at the same file through "nano" shows garbled characters. On my local machine (with practically identical Arch software versions) on the other hand, both "cat" and "nano" show files with these characters correctly.
Last edited by Lazar (2010-09-19 15:13:59)

Hi,
Like BluShadow I'm curious to see a test case...
Depending on the way it's been created, the encoding declared in the XML prolog doesn't necessarily reflects the actual encoding of the content.
What's your database character set, and version?
Please also post the error message you get (LPX-00200 probably?).

KDE (or GNOME?) non-latin chars input problem

Similar Messages

Maybe you are looking for