Hi, I make reference to a lot of German words in my writing. When I do so, I sued the standard style recommendation of setting a foreign word in italics. When I hit cmd-I to start typing in italics, then type a German word with an Umlaut, like “Rücken,” the umlauted-u is set in Roman type, but the rest of the word is in italics. If I select the word and hit cmd-I twice (once for regular font, a second time to put the whole word in italics), then the umlauted-u properly displays in italics. This is very odd behavior!
Note, I’m talking about typing in the editor window, not the result of compiling.
Environment: Scrivener 3.4; Mac OS Sequoia 15.5; recent MacBook Air.
How are you typing the ü character, is it with the typical deadkey + letter approach? Which key to use will depend upon the keyboard layout, but mine for instance has you hold down Optu, which triggers the umlaut deadkey ¨ and then I press u again to affix it to the letter: ü.
This causes me no issues with Georgia-Italic, or any other font I tried.
While normally I would not suggest a workaround in a case like this, the actual suggestion is so much better than raw formatting that I wouldn’t even call it a workaround: have you tried using styles instead of raw formatting? It’s quite likely that if you create a character style called, e.g. “Foreign language”, and make it italic, that it will cause the same issue as there isn’t really anything fundamentally different at that level. But, with how Scrivener is designed, you can design styles to be writer-friendly as opposed to publication-friendly. You could for example use a subtle text colour instead of italics, and have the compiler strip the colour and italicise the text for everything marked with this style.
Again, I figured it worth mention since I see a lot of people using raw formatting everywhere, and I also see a lot of woe from doing so—people need to change all of the formatting for some reason, and ask how to “search and replace” formatting, finding there is no such thing. Had they used styles though, it would have been one simple fix in their compile settings; thirty seconds instead of hours of painstaking manual labour or complex, potentially lossy round-tripping to more complicated word processors that have such features.
I write in French.
When I imported my project previously written with Word, I had many typing issues to correct.
With “search and replace”, it took me less than 5 minutes to clean my whole project in Scrivener, including all my research, notes, etc.
It even found mistakes in pdf files not possible to replace of course
Mindblowing
I think I am doing what you call “raw formatting.” And yes, typing opt-u u for ü.
I have used Mellel for years, and it does a version of that formatting. I found it cumbersome. I felt a return of ease when I started using Scrivener recently and I could just hit cmd-I to start italics. In Mellel I had a character style (a font variation) for German and Latin, as well as for German set in Roman type.
I gather Scrivener relies on Mac OS’s built-in language-recognition -spell-checking functions, so there’s no provision to set the language of a particular word or phrase.
Okay, that sounds like pretty typical input then, and it should definitely work. If it broadly didn’t I’m sure we’d hear no end of it from those that write in German, Spanish and so on. I just wanted to make sure you weren’t inserting characters out of the Unicode character browser or from a scratch pad.
A few diagnostic steps to try:
Test with other fonts, particular those that came with the Mac as opposed to any you have installed (I’m not sure if Georgia comes with it).
Test in TextEdit, by first making sure it is in rich text editing mode (there will be a formatting toolbar), and then using the Format ▸ Wrap to Page menu command. This will force it to use the same, more sophisticated, text engine Scrivener does.
This will help determine whether it is a problem with the font, specifically, or something broader at the system level.
I gather Scrivener relies on Mac OS’s built-in language-recognition -spell-checking functions, so there’s no provision to set the language of a particular word or phrase.
That’s correct, they have preferred some manner of algorithmic recognition (and that’s at the paragraph level I believe) to directly setting such data to text. But I don’t think that would have anything to do with retaining inline character formatting from one keystroke to the next. There isn’t anything inherently German about the Unicode character itself, and were we to insert a character that depicts a double-arrow, like so ⇒, if the font has an italic glyph for it, it should be italicised (as you may well see it in your browser, as I put Markdown around it for emphasis/italics).
Test with other fonts, particular those that came with the Mac as opposed to any you have installed (I’m not sure if Georgia comes with it).
Georgia does come with MacOS, FTR. I tried it with Times New Roman, and it doesn’t seem to happen with it.
Test in TextEdit, by first making sure it is in rich text editing mode (there will be a formatting toolbar), and then using the Format ▸ Wrap to Page menu command. This will force it to use the same, more sophisticated, text engine Scrivener does.
I tested in TextEdit, as you recommended, and it does not happen there.
I used your suggestion of creating a character style for foreign words, using italics but not bound to a font, and it is working smoothly.
I have also noticed that the problem I’m having is not consistent. I’m beginning to think that I may have some conflicting instructions in my style definitions or something. Not sure.
I’m a longtime WYSIWYG writer, and there’s a bit of, not exactly a learning curve, but an adjustment curve to writing in the Scrivener environment. I’ll keep trying to adjust! Scrivener has so many features I love (esp. for wrangling a big project) that I want to “master” it.
Thanks for the update! If you’re happy with using a style for this, then don’t bother with the below unless you’re feeling generous with your time and want to track down a potential bug.
I have also noticed that the problem I’m having is not consistent. I’m beginning to think that I may have some conflicting instructions in my style definitions or something. Not sure.
Given that it seems to come and go, my guess is more along the lines of it being timing related (Scrivener does more than TextEdit, obviously, so sometimes it can cause problems to manifest that a very simple environment will not), or perhaps a secondary effect of some other tool that you use that might be monitoring keystrokes or input in general. Common culprits there are Keyboard Maestro, BetterTouchTool, clipboard managers, and text expansion utilities—but don’t rule out the possibility if you don’t use any of those, you’d be surprised what all might be looking for shortcuts or keystrokes in a global fashion.
A pretty good way to test for interference like that is to log out of your account, then log back in with the Shift key held down for the duration of the log in procedure. This will inhibit the launching of most background utilities (the exceptions being deeper system-level stuff like Little Snitch, you need to do a safe boot to avoid stuff like that). Then for a time try to use nothing but Scrivener, and see if the problem goes away entirely. If it does, it’s a matter of auditing the tools you tend to use while working normally. My advice is to run one for a while, and if nothing returns, run the second, and so on.
But, generally, I would expect TextEdit to exhibit the issue as well, if it is a third-party utility issue. The only exception to that is how specifically you tune such tools, as many are capable of scoping their actions to specific applications, or even windows.
Thanks for the follow-up Amber. I discovered (by keeping the Styles Panel open) that when I type ⌥-u followed by u (to type ü), the character style resets to “no style,” but only for that character! (That is, if I activate the Foreign Word style, then type “Rücken,” the style turns off for the “ü” and then back on for “cken.”) That is very strange behavior! It also doesn’t happen all the time.
I am trying the safe mode boot technique. I MAY have found a culprit: Text Expander. But I’m not sure. (I also can’t live without Text Expander, I don’t think, esp. when writing professionally.) I’ll keep testing and fiddling around, and if I discover anything definitive, I’ll post it here.
Thanks for the update! I can definitely understand not wanting to turn off a text expansion tool, even to just add an exclusion for one program! I would feel like a courtroom stenographer without my chorded keyboard if I turn it off. Well, there are alternatives that might work, like Typinator (which probably can import your settings, but I don’t know). The one I use (Espanso) evidently has no issues.
If you have Nisus Writer Pro, it might be good to check there. This also uses the native Mac text engine, but unlike TextEdit (and more like Scrivener), it has a lot of custom code on top of it. They have full-featured free demo that would suffice to give it a quick try, as well.
My thinking is that if even basic italics are disrupted, there probably isn’t anything we can actually do about it. Both the dead-key text input itself and the font family variant selection are pretty “low level” as far as we’re concerned, and if this is messing up style recognition too, it indicates that the internal objects used to hold attributes on text are being aborted somehow.
An interesting point of trivial is that you would expect something like that if the requested character doesn’t exist in the current font, like if you insert a Chinese word into most Western-oriented fonts, it’s going to switch to PingFang SC or something for that character. So there is an intentional mechanism, deep in the text engine, that would do this, but it shouldn’t be happening for what you’re doing, at least not with mainstream fonts like this that would have all standard European characters in all font face variants.
Thanks for the suggestion, November_Sierra. I might try that and see what happens. I’ve resisted it, just because of possible confusion. I DO use a German keyboard layout on my iPhone when I’m texting German friends, but that doesn’t involve exactly typing.
In any case, it would be interesting to see whether this solves the problem.
As you know, I’m a long-time user of both Scrivener and NWP (latest versions of both), so I’ve been trying this out and have no problems with umlauted vowels in Georgia Italic whether bold or otherwise in either app. That’s on an M2Pro Mac Mini running MacOS 15.5. I’m sure there will be no problem on my M1 MBA either.
I used to use Text Expander but abandoned it when they priced me out of their market; so I can’t test that. I too use Espanso now (though I do have a small issue with that which I’ll take up with the developer when I get round to it).
It does seem to me that if I type ü by pushing the u and holding until the contextual diacritics menu pops up, then hit 4 for the Umlaut, there’s no problem. That is not my wonted way of typing the letter, but if it works, it works!
In French, there is ù which requires me to first alt-key something then u. (alt+[, u)
I really don’t like it, it stops me in my tracks (I type fast) and there is no “one-key” alternative for it. (Some keyboards have the extra key, but most don’t.)
So, since in French there is no occurrence of a double u, uu, not a single word, I’ve set a substitution.
uu = ù
After that it quickly becomes a reflex to simply type uu.
Perhaps that would work for you?
Worst case scenario, if uu is in your language, you could use uuu.
It think it would be less demanding to execute than how sounds your current solution.
not possible to replace of course 
