[Net Core][LOC]The ‘Misc’ component is not translated in local languages OS

[Vino-Wang]

• .NET Core Version: 3.0.100-preview6-012067

• VS: Dev16 16.2 Preview 1 d16.2 28921.214

• OS: CHS RS3 X64

• Affected OS: CHS, CHT, CSY, DEU, ESN, FRA, ITA, JPN, KOR, PTB, RUS, TRK, PLK 13 languages

• Have you experienced this same bug with .NET Framework?: No

Problem description: The ‘Misc’ component text is not translated in local languages OS.

Actual behavior: The ‘Msic’ component is not localized in local languages OS. e.g. CHS

Expected behavior: The ‘Msic’ should be translated according to the corresponding languages.

Minimal repro:

1. Install latest VS & .NET Core 3.0 on CHS machine, then open the attached app. FrameworkApp.zip CoreApp.zip
2. Run it and observe the Misc component headers of PropertyGrid.

[lukaschal]

Localized in a xlf file.

File: System.Windows.Forms\src\Resources\xlf\SR.xlf ID: 0; "PropertyCategoryMisc" SRC: Misc TGT: 杂项

https://github.com/dotnet/winforms/blob/master/src/System.Windows.Forms/src/Resources/xlf/SR.zh-Hans.xlf

[RussKie]

I've debugged our code, and it appears we get "Misc" string from .NET Runtime

I run our test app with "ru-RU" locale, and here's what I got as a return from this call for a TextBox control:

Property	Category
AcceptsReturn	Поведение
AutoCompleteMode	Misc
AutoCompleteSource	Misc
AutoCompleteCustomSource	Misc
CharacterCasing	Поведение
Multiline	Поведение
PasswordChar	Поведение
ScrollBars	Внешний вид
Text	Внешний вид
TextAlign	Внешний вид
UseSystemPasswordChar	Поведение
PlaceholderText	Misc
AcceptsTab	Поведение
ShortcutsEnabled	Поведение
BackColor	Внешний вид
BorderStyle	Внешний вид
ForeColor	Внешний вид
HideSelection	Поведение
Lines	Внешний вид
MaxLength	Поведение
ReadOnly	Поведение
WordWrap	Поведение
AccessibleDescription	Специальные возможности
AccessibleName	Специальные возможности
AccessibleRole	Специальные возможности
AllowDrop	Поведение
Anchor	Макет
CausesValidation	Фокус
ContextMenuStrip	Поведение
Cursor	Внешний вид
DataBindings	Данные
Dock	Макет
Enabled	Поведение
Font	Внешний вид
Location	Макет
Margin	Макет
MaximumSize	Макет
MinimumSize	Макет
RightToLeft	Внешний вид
Size	Макет
TabIndex	Поведение
TabStop	Поведение
Tag	Данные
UseWaitCursor	Внешний вид
Visible	Поведение
ImeMode	Поведение

[weltkante]

it appears we get "Misc" string from .NET Runtime

Not really, the .NET Runtime code will look at attributes defined on your classes/properties via reflection or a registered dynamic TypeDescriptorProvider. If the type you are looking at is in your assembly you are still responsible for properly annotating it, even if the data is retrieved through .NET Runtime infrastructure.

From a quick look, the properties in question are missing [SRCategory(...)] attributes. If you meant that the default value for properties not annotated otherwise is coming from .NET Runtime and not being localized, that may be true.

So the question is probably whether you want to push .NET Runtime to localize their default value, or if you just want to annotate all designer visible control properties with SRCategory to ensure they are localized.

[RussKie]

your assembly you are still responsible for properly annotating it

Yes, however it may be a stretch to expect all properties on a given object annotated - one can bind an arbitrary object to a property grid. Without spending too much time and debugging TypeDescriptor it is hard to tell where "Misc" string comes from, but it doesn't appear come from us in any shape or form.

Further .NET Runtime is not being localised at all (no plans for that either), which is likely what brought us here.

[weltkante]

Further .NET Runtime is not being localised at all

They are localizing exceptions, unless they reverted that decision. It already has been aknowledged that some exceptions are exposed to end users (not just developers) via WinForms and WPF binding and validation systems.

I'd expect this TypeDescriptor situation fall under the same rules, it can end up with the end user if someone places a PropertyGrid in his application, so it should be localized like exception messages.

If it were design-time visible only you could probably argue to override defaults by installing a TypeDescriptorProvider instead of annotating every single property. But for runtime end-user facing behavior its better to fix right at the source since there is literally no situation where you don't want this localized.

[RussKie]

@nakarnam FYI

[elachlan]

So is the fix in runtime and not winforms? Should we move it there? It seems more correct to me, since its the default and if a property is missed when annotating, it will still show as misc.

[elachlan]

CC: @dreddy-work / @merriemcgaw can we move this to runtime or should it stay here in winforms?

[dreddy-work]

runtime should be localized by now. @Olina-Zhang , does this till repro?

[Nora-Zhou01]

Verified on latest 8.0 build .NET 8.0.100-alpha.1.23060.24，the "Msic" component is still not localized in the local language OS, but the location has changed.

[weltkante]

So is the fix in runtime and not winforms?

No, I was saying that the runtime is localizing certain things, and so should WinForms. This is declared in WinForms so it should be localized there.

The question is whether hosting a PropertyGrid for WinForms controls to the end user (not the developer) is still a supported scenario. It was in Desktop Framework but a lot of the designer hosting has been moved outside WinForms into a VS component, so I don't believe its currently reasonable to host a control designer to the end user? (It still is possible to build custom designers, but I'm not sure if its intended to be used with the WinForms controls, or just is left around to be used by 3rd party report designers and the like.)

The team has to comment on their plans in that regard, it may be possible to drop this issue if these properties are no longer designable in hosted designers.

[elachlan]

This is declared in WinForms so it should be localized there.

We already have a translation for it: https://github.com/dotnet/winforms/blob/a1aa54dff0f6635d3dfb1381aecc0d5d79ed254a/src/System.Windows.Forms/src/Resources/xlf/SR.ru.xlf#L8240-L8244

Which is only used in: https://github.com/dotnet/winforms/blob/a1aa54dff0f6635d3dfb1381aecc0d5d79ed254a/src/System.Windows.Forms/src/System/Windows/Forms/ComponentModel/COM2Interop/COM2ICategorizePropertiesHandler.cs#L14-L32

BUT, if you look at the Attributes we use [SRCategory(nameof(SR.CatBehavior))]. Its using the localization from runtime. As far as I can tell there is no SR.CatMisc.

[elachlan]

I found this in runtime, I am unsure if it is related. https://github.com/dotnet/runtime/blob/76b5b76ceb08baa587178f8654df1a964547930b/src/libraries/System.ComponentModel.Primitives/src/System/ComponentModel/CategoryAttribute.cs#L199-L226

[elachlan]

okay, found it.

So the default constructor of CategoryAttribute uses a category value of Default. CategoryAttribute.Category property calls GetLocalizedString which maps Default to SR.PropertyCategoryDefault.

PropertyCategoryDefault is located in Strings.resx: https://github.com/dotnet/runtime/blob/76b5b76ceb08baa587178f8654df1a964547930b/src/libraries/System.ComponentModel.Primitives/src/Resources/Strings.resx#L84-L86

Trying to override it in Winforms does not work and runtime doesn't localize those values as far as I can tell (no xlf folder).

So we would have to ask runtime to localize those values.

[elachlan]

@merriemcgaw / @dreddy-work I think this is where the winforms team needs to have a look.

[dreddy-work]

@merriemcgaw / @dreddy-work I think this is where the winforms team needs to have a look.

Thanks @elachlan for looking into it. Currently, localization during runtime is somewhat disconnected. I will consult with the team and potentially move it to the runtime repository afterwards.

[elachlan]

Thanks!

[elachlan]

@dreddy-work I stumbled across this issue again. Was there any movement with it?

[elachlan]

@merriemcgaw I believe we narrowed this down to a runtime issue. Should we move it?

[merriemcgaw]

It looks like it.

[Zheng-Li01]

https://github.com/microsoft/winforms-designer/issues/827, the "Design" node is not localized in the VS Properties window.

[merriemcgaw]

@Zheng-Li01 this last one should be filed in the WinForms runtime repo as it's a different problem than this issue I believe.

[Tanya-Solyanik]

@Zheng-Li01 @merriemcgaw we'll track this issue in designer https://github.com/microsoft/winforms-designer/issues/827, we'll have to override these values when creating shadow properties in order to localize them according to the VS ui culture

[Tanya-Solyanik]

Closed by accident, we can fix this issue only in the VS, not in the runtime applications.