Hello sir,
Totally agree with your general sentiment; while the solution continuously evolves adding new features and enhancements, it must maintain its internationalization support for regional locales across various system configurations. Otherwise, IT, admins, and end-users are strained with unnecessary, sometimes drastic actions to recover from an incident that should never be. If the community sees such experiences across our solution upgrades, please lets start a new thread and collect the feedback together, so we may tackle this matter holistically and involve the right teams.
Although not an installation limitation necessarily, you make a good point to preventatively note it as installer’s known issue. I’ll share this feedback internally as the fix is expected tomorrow, and make a call for future. Nonetheless, given the tool starts up within minutes, validated a workaround, the immediacy of a hotfix, and our strong mission for a globalized product, I recommend against reinstalling OS with user account ‘cleaned’ from special unicode characters - to me, this seems excessive, considering. Instead, as suggested before, kindly reach me via private message to help in case the quick workaround does not resolve your slow app starting situation.
All said, I totally empathize with the affected users wanting a fast app launch. I too have non-standard ascii characters in my name, yet dont recall the last time to have used them with critical system/product deployments; very likely induced by perpetuated inconsistency across many tools I use on daily basis over the years, feeling deeper responsibility to make this right the first time! As we deepen our interop with technology, in the event you are standing up a new machine, reinstalling an OS, or standing up a broad solution for your company, I would agree with Günther’s note that one might want to pause and consider neutralizing special unicode characters from system names and account usernames substituting with their relative ascii approximations, if any e.g., ü to u, or ш/š to s/sh, etc. Again, this isn’t an endorsement to do so, nor I claim there is plausible substitution path (most definitely not for non-latin, double-byte locales such as chinese and japanese). Rather, use your past experience to make your professional lives easier, if offered the IT discretion to make those choices for everyday tools :). Please note that Autodesk is totally committed to a consistent internationalized experience over time and to strengthtening our supported culture codes and locales.
Have a pleasant weekend,
Martin Gasevski | Fusion 360 Team Product Manager