There could be used for .txt files a custom syntax highlighting file which has multiple color groups for the various quotes. After downloading the attached syntax highlighting wordfile into the directory %APPDATA%\IDMComp\UltraEdit\wordfiles and restarting UltraEdit on currently running, open the Manage Themes dialog, select tab Syntax, select the Language Text and configure good visible text and background colors and perhaps use additionally the font style bold for the quotes.

The syntax highlighting wordfile defines also „ and “ as brace strings. The matching double quotes are highlighted with the colors defined for Brace highlight on tab Editor in the Manage Themes dialog. There is no brace highlighting on other quotes and the commands Select to brace and Go to brace can be used for selecting the string between the correct double quotes respectively go to the matching double quote.

There can be run from top of the file a regular expression replace for the other double quotes using ["”] and use as replace string first just „ for correcting all double quotes one after the other with visual inspection at the beginning of a quoted text. Next run from top of the file again a regular expression replace searching for ["”] and use as replace string now just “ for correcting all double quotes one after the other with visual inspection at the end of a quoted text.

UltraEdit has no AI feature to understand the text and know like a human reader where a quoted text begins and where it ends and if a straight double quote must be used like in a code example or after a number on which " means inch or arcsecond.

I have seen too many web pages with code examples in world wide web on which straight double quotes were replaced obviously automatically most likely by a word processing application by text quoting double quotes making the code examples invalid for usage. The result is that many beginners in code writing copy the code examples from such web pages and wonder why the script code does not work or the compiler outputs error messages on code compilation.

UltraEdit for Windows v24.00.0.42 to v26.00.0.72 have a bug regarding to characters with a code point value greater 127 decimal in a Windows-1252 encoded wordfile, i.e. non-ASCII characters in an one byte per character encoded wordfile. I reported this issue as detected by me. It was fixed with v26.10.0.14 which syntax highlights ANSI characters as it worked up to UE v23.20.0.43. I found also a workaround for this issue. The wordfile must be stored as UTF-8 (without BOM) or UTF-16 encoded Unicode file. Then the syntax highlighting of the quotes works independent on which characters are left and right as being now interpreted themselves as word delimiters as I could verify with restoring UE v26.00.0.72 from my archives.  UltraEdit 26.10.0.72 works in my test with Windows-1252, UTF-8 and  UTF-16 encoded text.uew. The default system ANSI code page is Windows-1252 on my PC because of having German as language and Austria as county configured for my account in the Windows settings and UltraEdit uses the default settings. I recommend to check your encoding settings at Advanced - Settings or Configuration - File handling - Encoding in UE v26.10.0.82. The attached screen shots are made with Windows-1252 encoded text.uew.

Brace matching for the low and left double quote requires UltraEdit for Windows v2022.0.0.70 as I found out today. Former versions support brace matching only for ASCII characters independent on the character encoding of the wordfile. There is no possibility to get brace feature working for non-ASCII quotes in former versions of UltraEdit as far as could find out with some quick tests.

The syntax highlighting wordfiles in GitHub repository or UltraEdit´s wordfiles download page are all user contributed and not deeply analyzed by an employee of UltraEdit, Inc. They are reviewed of being really a wordfile before they are added to the master branch and uploaded to the web server, but there is no syntax check made neither for the wordfile syntax nor how good the syntax highlighting wordfile really works for the language being highlighted. There is no "standard wordfile" for .txt files.

It is up to you to customize the wordfile provided by me for your needs on .txt files highlighting. The line beginning with /Delimiters = can be extended with more characters to interpret as word delimiters on syntax highlighting the text in files with file extension txt. The order of the delimiters on the line does not matter although I sort them always alphabetically according to their code point values using an UltraEdit macro.

Lines of Windows-1252 encoded text file for testing quotes highlighting:
PS: The image format PNG is much better for screen shots than the format JPEG. The Portable Network Graphics format is supported by all applications supporting also the JPEG image format.

I updated my previous post with screen shots of quotes highlighting as done by UltraEdit for Windows v26.10.0.72 on Windows-1252 encoded text file with Windows-1252 encoded syntax highlighting wordfile. There is no problem on interpreting all the quotes as word delimiters and highlight the quotes according to color configuration in the manage themes dialog window.

I am not aware of a public released 26.10.0.82. I have archived only version 26.10.0.72 and as next public released version 26.20.0.4. I see no difference between v26.10.0.72 and v26.20.0.4 regarding to syntax highlighting of the quotes. I do not understand why “ after a dot is interpreted as word delimiter on having configured just a background color for the color group with this quote character while the same text file with same wordfile is interpreted different on having configured just a text color for the color group with character “. I can see the differences on your two screen shots, but it is completely unexplainable for me from a programmers point of view. Further, I do not understand why it makes a difference on comma or question mark left to “ in comparison to a dot. The character “ itself should be interpreted as word delimiter and therefore the character left and right should not matter at all. However, I have not UE version 26.10.0.82 and cannot analyze for that reason that strange syntax highlighting behavior by myself.