Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zh-CN and zh-TW .NET resources are not generated in windows-latest (windows-2022) #5189

Closed
1 of 7 tasks
JustArchi opened this issue Mar 7, 2022 · 8 comments
Closed
1 of 7 tasks
Assignees
Labels
Area: .NET Framework bug report investigate Collect additional information, like space on disk, other tool incompatibilities etc. OS: Windows

Comments

@JustArchi
Copy link

JustArchi commented Mar 7, 2022

Description

One of the users of my ASF software has reported that the program is missing zh-CN (Chinese simplified) translations. After short investigation I came to conclusion that this had to be GitHub runner environment change, as I couldn't narrow it to any other component. A quick commit for testing has confirmed my suspicion, as downgrading the image from windows-latest to windows-2019 fixes the issue and there are zh-CN resources generated again.

Virtual environments affected

  • Ubuntu 18.04
  • Ubuntu 20.04
  • macOS 10.15
  • macOS 11
  • Windows Server 2016
  • Windows Server 2019
  • Windows Server 2022

Image version and build link

Build on windows-latest which doesn't include correct translations: https://github.com/JustArchiNET/ArchiSteamFarm/actions/runs/1945418953

  Environment: windows-2022
  Version: 20220227.1
  Included Software: https://github.com/actions/virtual-environments/blob/win22/20220227.1/images/win/Windows2022-Readme.md
  Image Release: https://github.com/actions/virtual-environments/releases/tag/win22%2F20220227.1

Build on windows-2019 which does: https://github.com/JustArchiNET/ArchiSteamFarm/actions/runs/1946785489

  Environment: windows-2019
  Version: 20220227.1
  Included Software: https://github.com/actions/virtual-environments/blob/win19/20220227.1/images/win/Windows2019-Readme.md
  Image Release: https://github.com/actions/virtual-environments/releases/tag/win19%2F20220227.1

Both happened the same day, 5 hours apart, so I'm pretty sure nothing else affected the outcome.

For verification, download windows-latest_ASF-generic and windows-2019_ASF-generic artifacts. In the downloaded zip file navigate to zh-CN folder, there should be ArchiSteamFarm.resources.dll file available, which doesn't exist in windows-latest run.

obraz

Is it regression?

Yes, windows-2019 works fine - https://github.com/JustArchiNET/ArchiSteamFarm/actions/runs/1946785489

Expected behavior

If there are zh-CN resources, they should be embedded in the resulting build output. This is what happens with all other languages, such as pl-PL among others.

Actual behavior

zh-CN and zh-TW resources are missing, only those two seem affected, as other translations are working just fine. I suspect some missing cultures installed or something like that, there is for sure some difference in 2022 version compared to 2019 in this regard. Sadly I'm unable to assist further as I don't know what exactly is missing, in fact I'm surprised something is.

Repro steps

You can run my public publish.yml workflow, publish job is enough, simply replace windows-XXX in OS matrix to the one you want to test. You can analyze the output windows-XXX_ASF-generic build artifact, where XXX is the windows version that was used for build.

Alternatively, you can also build the program source manually:

# Install latest 6.0 .NET SDK if needed: https://dotnet.microsoft.com/en-us/download/dotnet/6.0

git clone https://github.com/JustArchiNET/ArchiSteamFarm.git
cd ArchiSteamFarm
dotnet publish ArchiSteamFarm -c Release -o out -f net6.0

# Verify if out/zh-CN/ArchiSteamFarm.resources.dll exists, it should at least on windows-2019
Get-ChildItem out\zh-CN

Thank you in advance for considering this issue, let me know if I can aid you further in any way. The project and all resources are public, so reproducing it shouldn't be an issue.

For now I've decided to downgrade the used version as part of JustArchiNET/ArchiSteamFarm#2533 - not ideal, but fixes the problem.

@JustArchi
Copy link
Author

JustArchi commented Mar 7, 2022

Additional info:

I don't want to analyze all the builds as that has little value, but the for record, windows-latest from 25 days ago worked fine as it was still pointing to 2019 variant:

  Environment: windows-2019
  Version: 20220131.1
  Included Software: https://github.com/actions/virtual-environments/blob/win19/20220131.1/images/win/Windows2019-Readme.md
  Image Release: https://github.com/actions/virtual-environments/releases/tag/win19%2F20220131.1

You can find its release here (V5.2.3.3).


The first problematic build (observed) was produced 11 days ago, where windows-latest already pointed to 2022 variant:

  Environment: windows-2022
  Version: 20220220.1
  Included Software: https://github.com/actions/virtual-environments/blob/win22/20220220.1/images/win/Windows2022-Readme.md
  Image Release: https://github.com/actions/virtual-environments/releases/tag/win22%2F20220220.1

You can find its release here (V5.2.3.4).

This confirms that 2022 version is the problematic one and not some internal upgrade across the same release.

@mikhailkoliada mikhailkoliada added Area: .NET Framework OS: Windows investigate Collect additional information, like space on disk, other tool incompatibilities etc. and removed needs triage labels Mar 21, 2022
@mikhailkoliada
Copy link
Contributor

@JustArchi Hi, thanks for the report! We will take a look.

@JustArchi
Copy link
Author

JustArchi commented Mar 22, 2022

@mikhailkoliada thanks for triage, you can consider adding .NET Core label as well, as this issue seems to affect both - .NET Framework and .NET Core, my ASF project builds a binary for both and it seems they're both suffering from the same issue - I've verified that checking -generic-netf package in addition to -generic which I've originally opened the issue about. Thank you in advance.

@dsame
Copy link
Contributor

dsame commented Apr 4, 2022

i confirm
windows-2019 has zh-CN and zh-TW locales installed
https://github.com/akv-platform/dotnet-locales/runs/5814137648
and windows-2020 has not
https://github.com/akv-platform/dotnet-locales/actions/runs/2089010332

i am looking for a reason and solving the problem

@dsame
Copy link
Contributor

dsame commented Apr 4, 2022

@JustArchi According to https://cldr.unicode.org/index/cldr-spec/language-tag-equivalences , namely the wording "This means that zh ~ zh-CN ~ zh-Hans ~ zh-Hans-CN, and that zh-Hant ~ zh-TW ~ zh-Hant-TW." at the very bottom

zh-CN and zh-TW replaced with their equivalents zh-Hans-CN and zh-Hant-TW

Can you use the OS provided locales?

@JustArchi
Copy link
Author

@dsame thank you for evaluation. Yes, I probably could rename my locales to those two. Give me a moment to give it a try and I'll come back to you with results.

JustArchi added a commit to JustArchiNET/ArchiSteamFarm that referenced this issue Apr 4, 2022
@JustArchi
Copy link
Author

@dsame After short testing it seems that zh-Hans-CN, zh-Hant-TW and zh-Hant-HK that I have, are all properly being generated on windows-2022. Thank you a lot for your help.

It's probably a good idea to document it somewhere on GitHub as some kind of "breaking change" in regards to target cultures on .NET. Since I did further digging and found out both zh-CN and zh-TW are kinda "obsolete" to use anyway, I don't believe there is anything to fix in this regard, just leaving a note should be sufficient.

Thanks again, I'll close this issue but feel free to re-open it if you believe such note is warranted and want to remind yourself about it 😎.

@dsame
Copy link
Contributor

dsame commented Apr 4, 2022

@JustArchi thank you for cooperation!

JustArchi added a commit to JustArchiNET/ArchiSteamFarm that referenced this issue Apr 4, 2022
* Attempt at resolving actions/runner-images#5189

* Clean up dockerfiles from no longer required workarounds
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: .NET Framework bug report investigate Collect additional information, like space on disk, other tool incompatibilities etc. OS: Windows
Projects
None yet
Development

No branches or pull requests

5 participants
@dsame @JustArchi @mikhailkoliada @marko-zivic-93 and others