xure

A bit late to the party but here's the updated Swedish translation. http://files.xure.se/projects/wpi/lang_sv.js

Updated new strings as well as fixed a couple of other minor mistakes. lang_sv.js

How about an option in wpi_theme.js to have the install button be able to be placed in the bottom corners (same as Theme_ExitButtonLocation does for the exit button)? I would love to be able to have the exit button in the lower left corner and the install button in the lower right.

Yeah... I didn't really check the code or test extensively since I was not going to report this yet. However after some minor testing it seems the error message comes from WPI detecting my system uses Swedish and recognizes it using ISO 639-1 (sv). So adding a file with those values will make the error go away (as it then knows there is a language file available). However when selecting and loading a language ISO 3166-1 (se) is used. At least that is how it seems to work, but I'm sure mritter could tell us if I got it wrong. I do believe that this is the likely issue since just duplicating the same file using both ISO standards removes the error as well as makes the translation be selectable as normal. Therefore I don't believe there is a case of missing lines or something similar. btw mritter: have you tried any graphical diff utilities for comparing files like WinMerge for Windows or Meld for linux? I would highly recommend both of them. EDIT: Man, I got confused there for a while 639-2 is the 3 letter language code, 3166-1 is the country code (se)

I too have noticed this message, since it started appearing in 8.0.0 (for me). In my case it is for the Swedish language rather than Danish. I was going to report it after I had updated the translation file as well but since you mentioned it I might as well confirm it. The reason for the error is that WPI checks for different locale letters than what the files are named. For Swedish this means that WPI looks for 'sv' but the translation file is named 'se' and for danish the file is named 'dk' and I would guess that it is searching for 'da' (not tested). To solve this rename the file accordingly, you also need to change the 'lang' variable in the first row of the file.

If this is a big enough problem to warrant any action I would agree with AlBundy33's suggestion of having default values either in the code or in separate configs (ie. useroptions_defaults.js) and load those values only if the standard configs haven't been written yet. As this would help prevent users accidentally or not knowingly overwrite their configs.

@stasys44: Sorry to ask but are you sure that you switched to the new layout?

Thank you <3 However, I would still like to highlight the issue with having irrelevant variable values written to the playlist because it is not written to disk during install. Although I guess I could make some custom edits myself if you are really against the idea.

Just double checked with a freshly extracted copy of WPI 8.0.0 went straight in to options and added two of the midi files that are included in the Audio folder. Changed the path to %temp%\WPI_Audio and still the paths in the .m3u playlist got evaluated to C:\WPI_Audio\<files> Edit: Actually, evaluated was probably a poor choice of words there. More like it doesn't matter at all what I type as the path it always gets saved as C:\WPI_Audio\<files> regardless if I use variables or not. (Sorry for the late reply, didn't have mail notification on this topic apparently.)

When changing the path for where to copy audio files to the hard drive the correct path does not get generated in the .m3u file. Also, (not really a bug but) if you use environment variables in the path those gets evaluated on the machine you used when configuring WPI and not the machine that you are installing windows on. Which makes variables a bit moot, as it is makes virtually no difference to write %systemdrive% instead of c:\ and as such could point to a non-existent location. Evaluating the variables during installation and putting the resulting .m3u in %temp% f.ex. would be a better solution imo.

(Late reply) I can see why you would want PNG's and not ICO's when you want to render them in html (which is why I uploaded PNG's). I tend to call those pictures icons regardless of what format they are in. Sorry that in my last post I didn't really make that clear. I know that there are some functions in system dll's to get the icons from exe's but I don't code in JavaScript myself so I don't know the limitations of the language and don't know if you even can call dll functions with js. I was mostly curious if there were any limitations or if you even had thought about the idea (now I know). I would also like to express my gratitude to you and Kel for developing this project. I know you do this on your spare time and basically do not make any money of it. That is all. Thank You!

By logo's I'm assuming that you mean their icons specifically. If so, is there some reason/limitation that would prevent you from extracting them from the exe itself? That should at least get you a 32x32 icon (in most cases) to use as a fallback. I still can see the need for extra/higher resolution images but why as low as 32x32? In any case I got together a very small collection of 64x64 ones (about 80 of them) which you can look through in case you find some usable ones: link NOTE: some icons may be of dubious quality, upscaled and whatnot.

Probably shouldn't have used the word 'disabled' as that could be taken as 'not visible'. What I meant was that the checkbox will not be grayed out under those conditions.

This is probably not a new bug, nontheless... When having two entries that both have each other as excludes and one of them has a grayed condition that evaluates to true, that entry will have the name (correctly) set to the disabled color but the checkbox will not be disabled.