Repository navigation
Settings window not localized #280
Description
Even if Start Menu is localized (and localization depends on chosen language in settings. That's OK), settings panel itself is NOT localized and is always in english, whatever the chosen language.
It was not the case (and localization of settings panel was OK) in ClassicShell 4.3.1
Version:
- Open-Shell: 4.4.142
- OS: Windows 10 Pro 1909 - 64bits
Activity
LaurentGrenet commentedon Dec 30, 2019
Actually, I've seen that the fr_FR.dll was missing in C:\Program Files\Open-Shell directory.
Copying file from ClassicShell 4.3.1, localization of Settings panel is there....
On the other hand, switching to another language do NOT download any new "language" dll, and CheckForUpdate button raises an error.
While in ClassicShell 4.3.1, language change propose to download the corresponding dll.
LaurentGrenet commentedon Dec 30, 2019
Closed by error.
Ibuprophen commentedon Dec 30, 2019
Just to clarify...
The issue regarding the "updates" feature has been stated (many times) before that this is currently a "broken" feature.
This specific feature was brought over from this software's predecessor (Classic Shell) that looks for updates via a location that is no longer maintained/exists.
~Ibuprophen
LaurentGrenet commentedon Dec 30, 2019
I don't know if it is maintained, but it's clear it still exist. With Classic Shell, it is still now feasible to download Dll for most of the languages.
terr72 commentedon Jan 14, 2020
It would really be helpful for many foreign speakers if this could be fixed.
@Ibuprophen: You stated in a different issue that it would require a lot of work to fix the integrated locale updater and the dev team simply doesn't have the time resources for it.
But if I understand LaurentGrenet correctly copying the language file from ClassicShell basically fixes the problem. Wouldn't bundling those locales be a much more time effective solution than trying to fix the whole user choice and remote download process?
WinSCP has also a very similar approach. It's English by default and if you want to localize it you need to download a simple ZIP file in your language, extract it into its folder and that's it.
coddec commentedon Jan 14, 2020
The language download option etc. is great and cool!
But for now, I reckon if we bundle all of the language dlls with the setup file/program as a fall back solution, it may help in this situation.
1 They are not huge, thus won't increase the setup binary dramatically.
2 Users can carry the binary and install it and change the language straight way with or without internet doesn't matter.
3 We don't need to spend a lot of time on the language downloading function for now, but there will be almost 0 impact on user experiences (language perspective.)
(4) Only issue I can think of is the dll permission/copy right etc. etc. Since users can download them easily without any notice, I presume it should be to be included with the setup binary?
@Ibuprophen @XenHat @ge0rdi
What do you guys reckon?
ge0rdi commentedon Jan 21, 2020
@coddec
Looking at translation DLLs, each DLL has cca 150kB and there are 19 of them. That's about 2.5MB.
Sounds quite a lot to me :(
I'd rather pack them together and offer as separate package on Releases page. So anyone interested in localized version could download them.
Also it will be great to have sources for them. AFAIK they are not part of source repo, we cannot compile them.
Will be great to ask Ivo about sources for those DLLs.
RegisStGelais commentedon Jan 21, 2020
or offer a package that include them (a multilanguage package) and another that does not.
RegisStGelais commentedon Jan 21, 2020
And yes, it would be grate to have a repo for them.
coddec commentedon Jan 25, 2020
@ge0rdi
Rely from Ivo,
ge0rdi commentedon Jan 25, 2020
@coddec
If we'd like to maintain these localization DLLs, we should have .RC files and be able to compile DLL from them.
It should be possible to decompile existing localization DLLs using Resource Hacker. Then we can create simple VS project for them and establish compilation.
coddec commentedon Jan 26, 2020
@ge0rdi
I've saved them in RC format and RES format (Just in case). :)
RC.zip
RES.zip
coddec commentedon Jan 26, 2020
Just in case, we also have a mirror for http://www.classicshell.net/translations/
at
https://coddec.github.io/Classic-Shell/www.classicshell.net/translations/index.html
Which can be used to download original .dll files
ge0rdi commentedon Jan 26, 2020
@coddec
Thanks.
Though there will be some more work needed on this.
Numeric IDS (that identify dialogs, strings) should be replaced by symbolic names (defined in resource.h).
Also many strings contain escaped characters (e.g.
xED) and these should ideally be unescaped, so that those strings are human readable.Anyways, I think it may be good idea to track this (conversion of binary translation DLLs to source) in
Projects. So that it is clear what needs to be done.Current issue (with missing localizations) can be solved quickly by packing existing DLLs to archive and putting it (along with instructions) to
Releasespage (or some other appropriate place).coddec commentedon Jan 29, 2020
Temporary Translation/Language Solution Added to Release page
Release page
4f46134
https://github.com/Open-Shell/Open-Shell-Menu
Home page
e151c69
https://open-shell.github.io/Open-Shell-Menu/
ge0rdi commentedon Jan 29, 2020
I guess it should mention
Open-Shellinstead ofClassic Shell.coddec commentedon Jan 29, 2020
@ge0rdi
You are right, sorry, I just copied it from the page 😂
Should be fixed now
Thanks!