More freedom in the Language creation #14736
Replies: 5 comments 11 replies
-
|
PR: #14738 |
Beta Was this translation helpful? Give feedback.
-
|
To me, this sounds like dangerous grounds to walk 🙈 Umbraco relies on the information saved in the culture info not just the string value. So we need to know how to handle number formats etc. I haven't tested, but maybe this suggestion on how to install cultures in the OS still works. dotnet/runtime#23802 (comment) Thereby the information will be available everywhere in .NET. |
Beta Was this translation helpful? Give feedback.
-
|
@bergmania Do you have any examples on where Umbraco uses the CultureInfo values so we could test if it works with custom cultures? As far as my quick testing custom cultures works quite well when using existing languages and country combinations like "en-CZ" |
Beta Was this translation helpful? Give feedback.
-
|
Hey @bergmania When creating a custom culture .NET I believe it will try and merge cultures it already knows to create the most correct CultureInfo for the custom culture. See the Unit test here: d8a5fed In the examples from the Unit test all tests will pass on Windows 11. 2 Fail on Linux: 8 Fail on macOS But even though the cultures isn't matching 100% between platforms I still think we could support custom cultures but maybe with a warning. Because as far as my knowledge goes Umbraco doesn't use the CultureInfo formatting directly in the output data anywhere I could think of - This might be wrong? In our case we need custom cultures be cause we have a variant of a website that doesn't match the language/country combination that already exists and in the case we need to format the data according to the culture we can either use the custom culture .NET provides us or make custom logic to handle our specific custom cultures if that makes sense 😄 What is our perspective on this? |
Beta Was this translation helpful? Give feedback.
-
|
Indirectly Umbraco relies on it due to ASP.NET Core. We set the thread cultures, and this is used by ASP.NET Core. So if you have a decimal field, the separator will be presented using "," in da-DK but with "." in en-US. In general, If we should support this I think we should avoid using CultureInfo all around the codebase, and only use it where it is required (E.g. for threads). As long as we are using CultureInfo, I still think the safest way is to install the cultures on the OS. |
Beta Was this translation helpful? Give feedback.
-
|
I hear you but I'm still wondering if this has any problematic impact on us developing with Umbraco. Wouldn't you be able to change the format of DateTimes, and decimal fields manually if you encounter a result that wasn't expected? Furthermore I tried wrapping the Asserts from the unit test I created to see all the failing results and here's what I found: Windows: Linux: MacOS: My point here is that on Windows & Linux it looks very usable out of the box and on all platforms you do get a fully functioning custom CultureInfo so even though you could have some problems with formats in some cases as using MacOS you could mitigate the problem by specifying how the data should be formatted before displaying it. As for the workaround of installing the Culture on the OS I agree that it's properly the safest but from a development standpoint this comes with a ton of challenges when onboarding new developers, deploying/hosting and the famous "It works on my computer" problem. I also tried the Windows approach of using the "Locale builder" and as far as I can see then all I can specify in the UI would end up being the same as I already get when creating a custom culture via the CultureInfo on Windows and Linux. And there isn't a described method of creating a custom culture on MacOS (I don't know if there exists a way). So now we better know the dangers of custom cultures so maybe we could include this in Umbraco as a "Use at your own risk" or "Experimental" feature I.E the warning I've mentioned before. The warning could include a link to a docs page where we can describe what possible problems we can see with using custom cultures and we can add any new problems we might encounter? |
Beta Was this translation helpful? Give feedback.
-
|
I take in up internally and discuss, but "Use at your own risk"-features is not really something what we want, due to potential support cases (I know the name suggests this should not be an issue). Worst case maybe we can make it easier to swap out from a package and thereby let you archive what you like. |
Beta Was this translation helpful? Give feedback.
-
|
Apparently this is already possible with a simple line of code: https://discord-chats.umbraco.com/t/16320837/how-to-add-custom-languages-to-the-add-language-dropdown-in- |
Beta Was this translation helpful? Give feedback.
-
I'm pretty sure this is not supported in the same way between operation systems. |
Beta Was this translation helpful? Give feedback.
-
|
It does exactly the same as I've described here in this discussion and how the UI change would have worked 😉 |
Beta Was this translation helpful? Give feedback.
-
|
Umbraco using dotnet by proxy uses ICU, an attempt at standardization for encoding cultures/serialization between cultures. ICU/CLDR is not meant for defining business language/region pairs, but for UTF-8 translations for data serialization given a sort of (dialect) of a language (typically in a specific region, though CLDR is a tree where language is fallback). So supporting a region would most likely choose to utilize an existing utf8 culture. Could it make sense to allow for defining a language by a "locale" name (or some other term) and a providing CultureInfo (given that CultureInfo is for UTF8 globalization but not necessarily business level region/language goals)? This code would also act as a deliminator in routing. So the Thread CultureInfo would still be a system level supported CultureInfo but the "business level" languages would be a user defined feature. Fundamentally the CultureInfo doesn't need to be the same as the content's "translation" e.g. OR (if my assumption is that most US French speakers are more likely utilizing Canadian standards Mock -> |
Beta Was this translation helpful? Give feedback.
-
|
Possible support could be found using concept of altName. There is a GetCultureInfo overload that looks like it might support this functionality already. The internal ctor uses the altName as the TextInfo and CompareInfo internal CultureInfo(string cultureName, string textAndCompareCultureName)
{
ArgumentNullException.ThrowIfNull(textAndCompareCultureName);
CultureData? cultureData = CultureData.GetCultureData(cultureName, false) ??
throw new CultureNotFoundException(nameof(cultureName), cultureName, GetCultureNotSupportedExceptionMessage());
_cultureData = cultureData;
_name = _cultureData.CultureName;
CultureInfo altCulture = GetCultureInfo(textAndCompareCultureName);
_compareInfo = altCulture.CompareInfo;
_textInfo = altCulture.TextInfo;
}some random test code |
Beta Was this translation helpful? Give feedback.
-
|
CultureData internally has a test for GlobalizationMode.PredefinedCulturesOnly, which is false by default on Umbraco dockerized into linux. So it would seem it will "support" any CultureInfo name.. given you provide an altName. # Use the SDK image to build and publish the website
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["Umbraco.csproj", "."]
RUN dotnet restore "Umbraco.csproj"
COPY . .
RUN dotnet publish "Umbraco.csproj" -c Release -o /app/publish
# Copy the published output to the final running image
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS final
WORKDIR /app
# Copy the published output to the final running image
COPY --from=build /app/publish .
# Copy the media items to the final running image
COPY ./wwwroot/media ./wwwroot/media
EXPOSE 8000
# Set the entrypoint to the web application
ENTRYPOINT ["dotnet", "Umbraco.dll"]Inside Program.cs : var t = typeof(CultureInfo).Assembly.GetType("System.Globalization.GlobalizationMode")!;
var prop = t.GetProperty("PredefinedCulturesOnly", BindingFlags.NonPublic | BindingFlags.Static)!;
var getter = prop.GetValue(null);
Console.WriteLine(getter);
var osNameAndVersion = System.Runtime.InteropServices.RuntimeInformation.OSDescription;
Console.WriteLine(osNameAndVersion);umbraco | False |
Beta Was this translation helpful? Give feedback.
-
|
@nul800sebastiaan Is custom language support still off the table for Umbraco moving forward? I don't believ I was hoping to open this conversation back up on adding a more customizable language creation option. Would it be possible to somewhat separate the concept of "language version" and actual ICU locales for the sake of improved platform footprint? It isn't possible to follow a "single tree" approach to content or a single site definition approach given that regional content cant be defined independent of ICU locale. |
Beta Was this translation helpful? Give feedback.
-
|
We still stand at this:
We have reduced usages of
Our focus for the rest of the year is very much on the "new" backoffice introduced in v14 and making sure people can easily migrate to v17 when that comes out at the end of the year. There's probably not much room to work on edge cases like this. |
Beta Was this translation helpful? Give feedback.
-
The feature I'm looking for
When creating a language you only have the languages provided by
CultureInfo.GetCultures(CultureTypes.AllCultures)which isn't always every option you need. Therefore it would be great to have an option to provide a custom IsoCode in the interface. As far as my quick test goes it shouldn't be a problem to have custom Cultures registered via the language. SourceExample of other people running into the same issue:
Example of missing language variant:
en-CZEnglish (Czechia)here we don't have an english variant for the czech republic which means if I would like to have a version of my website that's specific to the czech republic but written in english I would have to go about other ways of making my content tree instead of language variations.I found a workaround using USync where you can copy paste the from for example
en-ch:To a new file named
en-cz.config:After running the import your language will show but it would be much cooler if I could add the custom language directly in the Umbraco interface.
If you would like to know more about this issue take a look at the following:
CultureAndRegionInfoBuilderas a backup for missing cultures.Beta Was this translation helpful? Give feedback.
All reactions