I see the same as Duane - A mixed bag of English/German. Mostly German. My system is English.
Strange…
[quote=37993:@Peter Fargo]I see the same as Duane - A mixed bag of English/German. Mostly German. My system is English.
https://www.dropbox.com/sc/e9e5ziodlybzurc/drb8ZM_d3R[/quote]
Please test the following: Open the Package on OS X and in the Contents Folder, remove the de.lproj Folder.
That did it. All English now.
Oops… too soon. The File and Edit menus are still in German. Both the menu names and the menu items.
The About menu and MySQL Prepared Statement Helper menus are English.
The About window text in the text area is German.
That’s correct. I did not translate them yet.
But someone please explain to me, why non-german systems use the de.lproj Files?
I Build it with the language Selection set to “Default” and expected to build it for all included languages… 
[quote=38000:@Sascha S]That’s correct. I did not translate them yet.
But someone please explain to me, why non-german systems use the de.lproj Files?
I Build it with the language Selection set to “Default” and expected to build it for all included languages… :-([/quote]
Default means “whatever language the computer doing the build is using” NOT “English”
So if a person on OS X has their languages list set to include languages that you have NOT localized for and then German they’ll run in German
So, if i choose English as the language to build, will all the other languages still included in the build application? In ither words, if i choose english as build language, it will still use german in german systems?
The language you BUILD as has nothing to do with whether or not there are other languages included.
If you use dynamic constants they’ll all get written out to the various lproj (or mo) files with the right language code.
The build language is the language that the applications “default” dynamic constants are considered to be in.
They have to be treated as being in some specific language - and DEFAULT isn’t a language.
So if you have DEFAULT selected as the language & you run a German OS then the default values for dynamic constants are considered to be in German. If you take that exact same project & change nothing & recompile on a French system those strings are “French”. Recompile again on English & they are written as the English strings. So you see how “default” can be horribly confusing.
Selecting “default” for the build language in a multilingual world is a really bad idea.
Either set a specific build language OR always set a value for every localization so you NEVER use the default value.
It’s a long winded way of saying - Yes
If you build a multilingual app and have different strings for different languages then your app will “do the right thing” as far as choosing what strings to show.
For instance on OS X if you look at the Language & Text panel it will select the localization that is closest to the top of the users list. If it can’t match any it will fall back to using the development language as the last resort.
Thank you Norman.
I could not find a good explanation in the manual.
Maybe you could add your explanation to the manual?
Again, thank you.
Thank you Duane. The next release will be compiled with english as fallback language.
If you want to see the app in a different language then english or german, please just tell me which language you need and i will send you the Lingua file.
After you have added the translation for your language, you just send the file back and i can add is to the repo.
Thank you for your kind help.
I removed the folder you pointed to and it works fine. Thanks for all your efforts. This it a big time saver.
Is this trailing “1” after the “?” an error in the DELETE statement?
ps = db.Prepare("DELETE FROM Cvent_GroupMemberships WHERE groupmemberships_sllfid = ?1;")Also, would you be able to add in functionality for the SELECT statement?
This has all been a big help and I appreciate it very much.
Yes, this is an error. I will fix that with the next release.
I have already thought about it and will add it to my todo list.
Thank you Duane.
Just wanted to give you an update on the current progress.
I added the ability to define your own Field to Type definition, for each in Xojo available type of database. This is done by dragging a Type from the list on the right, to a Field in the list on the left.
The statements editor already respects your definitions.
Now i need to hardcode the default values for the Settings file which is created on first start of the app.
Then i will perform a few simple tests to make sure i can release 2.0. without any showstoppers.
The fine tuning will be done based on your feedback after i’ve released 2.0.
PS: Give me a few days, i am currently very short in my spare time…
Looks great Sascha.
that’s schweeeeet! Thanks! Whenever you’re ready, I am. No rush.
Next update open a new thread Sasha, as the current app isn’t a “MySQL Prepared Statement Helper” anymore. 
As soon as our current feature requests are implemented (Field to Type Editor, SELECT Statements), i will label it as Version 2.0 and create a new Thread with the correct title. 
I am nearly finished, but could need some help with testing the current state.
Anyone who’s interested, can from now on download the latests build from my Dropbox Build Folder.
I am very interested in feedback regarding the format of the created Update, Insert and Delete statements.
Thank you
PLEASE ATTENTION! I had to change the Settings File drastically. PLEASE REMOVE your old Settings file in you Documents Folder, before you start this Version for the first time!
Sascha - I double click and I get no user interface. The app seems to launch and quit.
OSX 10.8.5
The .ZIP file should unpack into it’s own separate folder. Try opening the zip with The Unarchiver. That decompresses it properly. The native Archive Utility didn’t seem to.
App opens fine after that (as far as I’ve gotten so far…)