Currently, when I paste JSON into a new tab in VSCode, it will usually detect its Language Mode as something else (ex CoffeeScript, etc, etc). Usually these are languages that I never use and don't care about.
Can I restrict the list of possible languages that it auto-identifies, so that it has a better chance of realizing that what I pasted in was JSON?
The description of that setting, Workbench > Editor: Language Detection, says that it can be scoped to restrict which languages it is applied to:
// Controls whether the language in a text editor is automatically
detected unless the language has been explicitly set by the language
picker. This can also be scoped by language so you can specify which
languages you do not want to be switched off of. This is useful for
languages like Markdown that often contain other languages that might
trick language detection into thinking it's the embedded language and
not Markdown.
So you could try this setting (in your settings.json):
"[json, jsonc]": {
"workbench.editor.languageDetection": false
}
This may only apply to previously set json files so let me know if this makes any difference. I don't think there is any other option other than disabling all language detection - of which I assume you are aware.
Related
I am currently trying to develop a VSCode extension that provides support for a new language. Static syntax highlighting should be provided by a TextMate file, additional semantic highlighting by a language server. Both of those use - for now - custom token types. The language server works nicely with Monaco and a corresponding Monarch syntax specification. With Monaco, I can set a theme manually via monaco.editor.defineTheme and provide rules for my custom tokens via rules: [{token:'my.tokentype', foreground:...}], and as a result, I get syntax highlighting the way I want, and the rules work for both Monarch-defined tokens and semantic tokens.
Now I want to do the same for VSCode. The TextMate grammar and the language server provide textmate token types and semantic token types respectively, and I now want to provide (themable) default styles for my token types in my extension, but I can't for the life of me figure out how to make VSCode highlight a document in my language based on my token types. Using the tokens and scopes inspector, I can see that the tokens in my document are assigned the right "textmate scope" or "semantic token type".
Now, how can my extension style those tokens? I have found the colors contribution point, but that can only provide colors (not additional styling like italic etc) and I have no idea how to assign those colors to my token types...
the only way I got VSCode to highlight anything is by using the semanticTokenTypes contribution point and declaring a default superType, but of course in that case, it will use the highlighting associated with that superType, not anything provided by my extension...
I have an iPhone app with interface languages in Toki Pona and Dothraki, which do not have ISO 639-3 codes. According to the ISO 639-3 standard, you can use the range qaa-qtz to represent languages for local use, which I have done (Toki Pona = qtp, Dothraki = qdt), but still get the warning from XCode "Unrecognized Locale".
It seems like I might be able to extend the main bundle class, but looking over the documentation, nothing seems to relate to adding non-ISO languages. I'm also aware of the text "If necessary, you can use a language or locale code that is not known to the NSBundle class or Core Foundation bundle functions. For example, you could create your own language designators for a language that is not yet listed in the ISO conventions or available as a language in Xcode." at the end of https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/LanguageandLocaleIDs/LanguageandLocaleIDs.html
In any case, I mostly want to get rid of this warning. Any help would be greatly appreciated!
https://forums.swift.org/t/proposal-ns-locale-identifiers-etc-should-have-custom-types/9367/8
have a look at the above link.
Check if the languages are added as Localizations
I believe I have a solution however slightly complicated one. You would need to create a setting option within the app to use those made up languages and to load them manually from a file when a user sets them. For example, let's say your app consists of one label and the user sets the option to the made-up language you would call a method to set the language and the text on that label would update accordingly. I don't know whether this makes sense to you?? Basically, if the user uses the made-up languages that would override any system localization they have. It is doable it would just take time to implement it.
Is there a best way to localize the language settings? Say the situation is that you have already a working application in, say, French, and wanted to completely localize it in English.
So is there any way to easily localize the application while minimizing the impact on the application's code, I mean there mustn't be any major changes to the code itself but adding some would suffice. I've heard of using resource files in VB6 but it seems to have an issue with its fonts specially in Japanese characters, it throws out a garbage chars specially on labels. Now, what's the best way to change the charset of a application without applying too much changes in the applications code.
This application has a legacy code to I have to deal with it.
I use resource files, and replaced (almost) every string in the codebase and UI with an ID.
Whenever I display a string, I then call a single function that takes a string like {#1234} and loads string ID 1234 (using LoadString() and returns it.
For the UI, I enumerate every control on the form and pass the visible strings to the same function.
This meant a single call to Localise Me in the Load event of each form and a TranslateString("{#1234}", "name", Name) whenever I set/display something dynamically.
For the fonts, see this example from the Visual Basic Programmer's Guide. I call this on every control as part of the Localise method.
Don't forget that different fonts and languages take differing amounts of vertical space for the same text. The form layout also needs to be adjusted to take this into account, or reflow dynamically (align controls to longest label, shift down to allow for longer full width text, etc.)
Regarding the "while minimizing the impact on the application's code" part of the question, I would suggest encapsulating the resource-lookup-related features into a class of its own, exposing methods to fetch a string (by passing a culture specifier argument).
Then the bulk of the work is to convert your code from perhaps hard-coded strings to method calls to retrieve the appropriate strings. Implementing a variant of this answer: Implementing String.Format() in VB6, could greatly simplify your life if you also encapsulate the notion of 'culture' and introduce some cultureInfo argument to this StringFormat method's signature (perhaps call it StringFormatLocal).
The point being, if the current app isn't localized, it's probably not concerned about localization; localizing it means introducing a new concern so in order to affect legacy code as little as possible, you'll need to seek & destroy "magic strings" and "magic formats" all over the code base (and if your UI has hard-coded design-time captions and images, remove those as well), replacing them with calls to your localization API - keeping the localization concern separated.
I'd like to see another answer here with more details about storing, loading and especially using non-ANSI string resources...
I need to make an application in which the user can toggle between two languages on triggering a click event on a button.
The problem here is that I have seen examples in which, if we want to load our localized nib file, then we need to change the language from the settings options and we can get the proper nib file loaded according to language selected.
I want to do this within my application, meaning I don't want to go to the settings menu and change the language and then reload the application.
I just want the above effect within my application (that is, through a button click event the app should be able to toggle between two languages).
Is it possible, and does Apple allow it?
Nobody here can tell you whether Apple will allow it, but if your app is well designed and there's a good reason for this departure from the usual way of doing things, you've probably got a good shot.
There's nothing to prevent you from loading a nib file localized for a different region. I'd probably avoid trying to use Apple's automatic mechanism, though. Just name your nib files using some pattern and load the appropriate one.
If you want your life to easy, you will take advantage of the Localization built into the operating system. Otherwise, you will have write your own methods to load localized strings or nib files.
There is no reason for Apple to reject an app that shows localized text based on an in-app setting. I work to help developers localize apps and, although I don't suggest this approach, they have done it and I've never heard of a rejection from Apple.
What you won't be able to do is use Apple's built-in tools, which rely on the system settings to determine a user's language and push the text from a Localizable.strings file. But it honestly won't take you too long to implement a similar system yourself using functions akin to gettext.
You essentially need to implement the same basic logic as any localization system:
1) Surround your in-app texts in a function that will display the proper language based on the user's chosen settings
2) Export your source texts (probably English into file
3) Translate the English strings into each language in a separate file
The function you write can follow the lines of gettext, which has examples in many programming languages. If the settings is "French" grab the equivalent string from the French file. If the setting is English, just print the English.
You won't be able to use Apple's tools, but you CAN do it on your own and Apple won't really care as far as I know. However, if you choose to localize into an Apple-supported language, follow this app localization tutorial for iOS using the standard Localizable.strings method.
Can I pass an argument to NSLocalizedString to override the localized string and tell it what language to use so that the user can choose a language from a Settings menu?
How so?
We’ve done something similar, but the answer was to not use NSLocalizedString. Instead, since you know what language the user has selected, you just load the text for that language. You can store it in property lists, using Core Data or SQLite, etc.