[GH-ISSUE #288] For auto language #1606

Closed
opened 2026-03-01 18:46:51 +03:00 by kerem · 2 comments
Owner

Originally created by @laiqun on GitHub (Mar 15, 2018).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/288

could you use
"System.Threading.Thread.CurrentThread.CurrentCulture.Name"
instead of "CultureInfo.InstalledUICulture" for auto language detection?

Originally created by @laiqun on GitHub (Mar 15, 2018). Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/288 could you use "System.Threading.Thread.CurrentThread.CurrentCulture.Name" instead of "CultureInfo.InstalledUICulture" for auto language detection?
kerem closed this issue 2026-03-01 18:46:51 +03:00
Author
Owner

@laiqun commented on GitHub (Mar 15, 2018):

The different between those ,already be discussed in this url:
https://stackoverflow.com/questions/329033/what-is-the-difference-between-currentculture-and-currentuiculture-properties-of

<!-- gh-comment-id:373249244 --> @laiqun commented on GitHub (Mar 15, 2018): The different between those ,already be discussed in this url: https://stackoverflow.com/questions/329033/what-is-the-difference-between-currentculture-and-currentuiculture-properties-of
Author
Owner

@spietras commented on GitHub (Mar 23, 2018):

If you mean what is happening in LocalizationHelper.cs after clicking on Autodetected language in Language options, then we need to use CultureInfo.InstalledUICulture, because it's the only one that always provides specific cultures (such as pt-BR as opposed to just pt). We have defined our own language codes management, so sometimes specifics are needed, sometimes neutrals. But we always should start from specifics. When we have a specific culture and there is a resource file for that culture, then we are good to go. If there is no resource file for that culture, we can check for parent culture (which is always neutral culture, for example, pt is the parent of pt-BR) and check if we have a resource file for that. Again, if we have that's great, but otherwise (which means that language is unsupported) we switch to the English language, which is always present and ready to use.

<!-- gh-comment-id:375775285 --> @spietras commented on GitHub (Mar 23, 2018): If you mean what is happening in LocalizationHelper.cs after clicking on Autodetected language in Language options, then we need to use CultureInfo.InstalledUICulture, because it's the only one that always provides specific cultures (such as pt-BR as opposed to just pt). We have defined our own language codes management, so sometimes specifics are needed, sometimes neutrals. But we always should start from specifics. When we have a specific culture and there is a resource file for that culture, then we are good to go. If there is no resource file for that culture, we can check for parent culture (which is always neutral culture, for example, pt is the parent of pt-BR) and check if we have a resource file for that. Again, if we have that's great, but otherwise (which means that language is unsupported) we switch to the English language, which is always present and ready to use.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/ScreenToGif#1606
No description provided.