When extracting strings from a desktop Windows application for translation, should I translate shortcut keys as well?
In other words, should Ctrl-C copy to the clipboard even for Chinese software?
Yes, CTRL-C is universal. You can safely assume that typical CTRL-something shortcuts behave the same in all (modern) Windows versions, regardless of the language.
However, there might be several ways to present them depending on the language. For example, French would translate the name of the key (the combination remains the same).
But you are asking about Chinese (presumably Simplified Chinese), which will simply display it as CTRL-C. After all, the keyboard layout is the same (with the same symbols), all they do differently is they use so-called Input Method Editors. And although there are several different IMEs, I haven't yet seen the one that would override CTRL-C...
Related
I would like to make my own version of Mac's ABC-Extended keyboard for typing Pinyin (a way to write Mandarin that indicates tones). But when I use Xcode, I just see a target custom keyboard extension for iOS and nothing for macOS. I've looked into the program Ukulele but it doesn't seem like it will do everything I need. Theoretically I could also put my rules into files like how this article indicates but that also seems cumbersome based on what I want my keyboard to do.
Here's what I want it to do:
First option: user literally types "ni3 hao3" and my logic in real time changes their output to "nǐ hǎo" (there are pinyin/grammar rules for where the tone mark goes)
Secondly (phase 2 in my project), in their user settings for the keyboard, they could indicate they want to convert their text to Hanzi (the characters). So when they type their Pinyin, my algorithm guesses a best guess list of Hanzi characters that matches their Pinyin entry. This would require that I have a downloaded dictionary file for my keyboard.
Thanks for any help! I know how to program it I just need the right software to use :(
I'm currently saving 200/300 PDFs a day (work related), they all have a sentence in that's the same, I'm unable to use Ctrl C/V as I have to copy other parts before saving.
Is there a way for me to have a keyboard shortcut that puts the sentence in for me when saving the file?
(Windows 7 and limited admin access)
Many Thanks,
L
You could use a Macro editor which records keystrokes and repeats them.
This one is a free portable example (doesn't require an installation).
https://portableapps.com/apps/utilities/tinytask_portable
On windows 7 you can only have one Item in the Copy&Paste Memory, so there is no other easy way than to simulate keyboard input. You can also "Drag and Drop" the sentence from somewhere else (like a website) by selecting it and then clicking on it and dragging it into the Document.
Maybe that works better for you.
I'm not sure I've understood completely your problem, but in all likelihood a clipboard manager would suit your case.
They don't (usually) allow you to have a sentence inserted automatically before saving, but they let you save many instances of "clippings" and paste them conveniently.
There are a lot of them, I personally like Clip and used also ClipX and Ditto.
Many of these clipboard managers include features to associate a specific hot key to insert a specific snippet of text.
There also programs that are focused specifically on that HotKey -> specific snippet functionality, or that include it among others.
Also, if clarified what software you're using to do these "pdf savings", it would help (it's possible that it does include facilities to include a sentence before saving).
And in any case you can almost for sure do what you want with a macro/scripting utility such as AutoHotKey (but it would usually be pretty complex if you're not already familiar with it).
I am working on several documents where I have to type [ ] { and the like (which is much easier with with an american keyboard layout (and to which I am used much more)) but where I also have to type Umlauts such as ä, ö and ü.
Usually, I go be setting up the (what I believe to be a standard) Windows Shortcut Alt+Shift to switch between these layouts.
This is unpractical, because at times I am not sure if I am already in the german layout when I need the german layout (and vice versa).
So, is there a better way to change the keyboard layout in Vim on *OS-level"?
I guess it could be solved with changed :map and :imap but I'd rather not use these for such porposes unless really forced to.
I don't think there is such an option - even though vim can even make pancake for you!
It'd be highly unlikely for any program to allow changing the keyboard layout of regular keys since basically any OS already supports it.
I am not sure if I am already in the german layout when I need the german layout
Do you have the language bar enabled? It should have an icon that represents your current settings.
Microsoft Knowledgebase article: HOW TO: Use the Language Bar in Windows XP
If the only thing that you need is to add umlauts easily, Vim has built-in support for adding these characters:
Method 1. In insert mode type: CTRL-K a: to give ä.
Method 2. If you use :set digraph you can enter a<BS>: to give the same result.
These methods will work with any character that needs umlauts, just use CTRL+K o: or CTRL+K u: respectively.
Source: http://vim.wikia.com/wiki/Entering_special_characters
Maybe you could be interested in some Dvorak layouts (mine is bépo, maybe it could suit you?)
I imagine that there are different combination, just looking for an affirmation. Or, are we developers really that english-centric?
If I were in Japan, using a word processor on some computer, would Ctrl + S save?
Are there keyboards where Ctrl + S doesn't even exist (non-english keyboards)? Most of what I've seen usually has latin + [insert language here] characters, usually overridden on the normal qwerty keyboard.
It depends.
If the application's UI is in English, most people will expect CTRL + S to save.
If you're writing an application that is going to be translatable, you probably want also the shortcuts to be translatable. Shortcut standard varies between languages and countries. Leave this to the translator.
Yes, Ctrl- and Alt- are usually passed on verbatim and not subject to IME processing—assuming one is using an IME; I don't know about IME-less JP input methods. But in the basic case where an IME is used, Ctrl-S remains Ctrl-S, it does not become Ctrl-す or something.
Furthermore, menu entries often have a Latin accelerator defined - cf. http://www.marsei.net/tec/tecladoEspWindows.jpeg :
addmenuentry(m, "ファイル(&F)");
Just tried on my Mac by setting Spanish as my default language. None of the programs I opened used different shortcuts in Spanish than English, although the menu text was all translated. TextEdit was the main program I used to test.
I also tried setting my keyboard to the Dvorak layout (very different layout, still meant for English), Spanish layout (still QWERTY), and French (a & q, z & w, m & , & ; swapped). Even though the French keyboard had the q in a different place, the shortcut was still CMD-Q.
So, it seems the convention on Mac OS X is to have the shortcuts always use the same letters.
However, according to this link, in Spain CTRL-G(uardar) is normally the shortcut for saving: http://www.ixda.org/node/18527.
Here's an argument for basing the shortcuts on the position of the key on the keyboard, but I'd be surprised if anyone actually does that. http://blog.i18n.ro/are-we-supposed-to-localize-keyboard-shortcuts/
In Visual Studio, CTRL + S saves the document. In MS Office it's the same if it's in English, otherwise if it's in Italian, CTRL + S underlines the text, while SHIFT + something saves the document. I have no idea why they did this, but it might also apply to other applications and languages.
It depends on what you want to write. if you want to write a program and want to publish it everywhere, you should decide if you want it to write in only one language or in lots of languages. If you only want to write it in English, every one that wants to use it should change his/her system language to English or at least should support English. In that way Ctrl + S will do what you want.
We're having trouble setting window captions using cyrillic or japanese characters. We either see question marks or random garbage, but not the text we want. We've tried using different encodings, SetWindowText(), SetWindowTextW(), SetWindowTextA(), and so on. We can't even get it to work by passing a string literal to SetWindowText().
Our Windows install does appear to have everything it needs - Internet Explorer and Firefox do show cyrillic and japanese captions correctly, for example. So I'm pretty sure we're not finding the correct encoding/method combination. Any suggestions?
The problem you've got (at a guess) is that the top-level frame window of your application is an ANSI window. Under the hood, when you create a window (with CreateWindow() or CreateWindowEx()) a window class must be supplied. This window class determines the window's properties, including whether or not it, by default, accepts ANSI messages or Unicode messages. In turn, this is set by whether you (or your framework) register the window class by calling RegisterClassExA() or RegisterClassExW().
What's almost certainly happing is that your top-level window's class is being registered with RegisterClassExA(). This means that the default window procedure for the window will translate all Unicode strings in messages to ANSI before processing them, hence the question marks and odd characters everywhere.
The easiest solution to all this is to just make your application Unicode throughout (usually done by defining _UNICODE). The other way is to figure out where RegisterClassEx() is being called, and make it RegisterClassExW(). This may cause ANSI/Unicode issues with other messages, but it should (in theory, at least) work. Of course, either way will break Windows 9X, if that's an issue.
If all this sounds horrendously complicated, you're not wrong ...
SetWindowText()? Did you compile your application as Unicode? If not, SetWindowText() is equivalent to SetWindowTextA(), which in turn is limited to your current system locale (aka "Language for non-Unicode applications").
Also, how did you CREATE your window? Using an explicitely Unicode-aware API such as CreateWindowExW()? If not, make sure that your program is compiled as Unicode.
If your program is not compiled as Unicode, you might want to either modify your "Language for non-Unicode applications" in CP/Regional Options. Reboot required. Or more easily: Use MS AppLocale to simulate a cyrillic system locale
You have to compile your application with _UNICODE defined. Otherwise all windows will still be MBCS and not utf-16 and therefore can't show cyrillic or japanese characters if the codepage doesn't match.