Hey,
My app in MAS has some languages shown that my app does not have. It’s english only.
Can I just remove the Resources/xx.lproj folders(except en.lproj) in the package to fix it or would that break other things?
My app is in english only and not localized in any way 
The translations are in MacOSLib. You can remove the lproj folders and the languages will disappear.
Aah, so thats why 
Thank you!
Or strip the localizations from your local copy of MacOSLIb
OR pick out only the bits you need from MacOSLib
That could also work and would probably be more efficient in the long run.
I’m finishing an update for my app in the store and hope that I’ll be able to submit it some day
We occasionally use some bits but with all the localization data it’s painful so we can’t just drop the whole macoslib in anything.
They end up having localizations that we have to go strip out.
So we mostly cherry pick a few bits - or just rewrite the declares 
It’d be nice to have all that data exported to lingua files & then you can add it IF you want it and not be forced to have it if you don’t
Then you can drop it in to any project and not be suddenly surprised like you were
If you use App Wrapper, you can strip them when preparing for the Mac App Store.
Having them there is the problem since, as the OP noted, his app suddenly appeared as being localized when he had not done it.
The mere act of putting MacOSLib in your app does this without warning or any obvious act you took.
He didn’t (apparently) knowing localize his app but suddenly it said it was.
Don’t get me wrong I like all the things in MacOSLib but this is one where I think its a mistake to do this in this way.
But I’m not the keeper of MacOSLib - so I just strip the localized data out when I grab a copy, keep the data and put it back in IF I DECIDE - not because someone else thought it’d be handy to have there 
@Norman Palardy It’s a difficult decision. While I can see how the MacOSLib containing these extra languages can cause frustration for those who don’t want them, it will save those who do, time.
I personally think it’s great if third party components do already include translations where necessary, however I guess what it then requires is a mechanism for enabling these languages when building?
I’ve added a feature request. <https://xojo.com/issue/31892>
As I said - the problem is that its quietly altered HOW your project compiles & behaves.
It’d be like the IDE quietly changing your project to build as Cocoa because - well we decided thats the right thing to do now.
MacOSLIb “decides” for me that I want these localizations - sometimes I do - sometimes I don’t.
So I strip it and add the ones I want when I want them - not when the MacOSLib maintainers decide to add a new one.
There’s already a mechanism to add localizations - add the Lingua data when you want it / need it.
If you don’t no sweat - import it & yer done.
Want specific localizations - drag those lingua files onto you IDE & yer done.
Its meant to be really painless.
Don’t get me wrong - I like macOSLIb - this is pretty much my only complaint.
As for a list well
there are currently 111 languages with the possibility of there being as many as 7600 (give or take a few)
That gets to be kind of a mind bendingly long list just with 111
I’m using its baby (App Wrapper Mini)
Norman has suggested to me that the localization data could be pulled out into Lingua files which could then be added to projects as wanted. Perhaps someone would like to pitch in?
I think there’s some confusion here because we’re approaching it from different angles, I’m coming from a post processing tool and the way I see to it is to isolate the lproj files (on the Mac) and then to allow the user to choose to keep them or not (I intend to improve this function in a future update).
The current problem I see with Xojo is that there are two ways to include localization data, one is to hard code into each constant (which is what we do and the MacOSLib), the other is to include language files (which I didn’t know is possible). If everything adheres to the second mechanism then yes it’ll work, but if a third party component still uses hard coded translations, then the user will still get localizations weather they want it or not.
Perhaps a possible solution is to reduce it to one method for localization?
Currently stripping the language folders via App Wrapper Mini is not possible, it’s only possible in App Wrapper because App Wrapper actually has access to the application, where as Mini creates a Xojo Script. I will consider this for the future.
I got caught out with this too, we started to translate an application into Chinese, and a third of the way through I had to do an emergency update to the app, without realizing Apple then release it as including Chinese… Even though it wasn’t fully. Thankfully it didn’t cause much frustration.
Localization files are a way to add a bunch of localized strings quickly - nothing more.
But if they are already IN something (like MacOSLib) they get added quietly and you have NO idea they exist (thats a different problem)
[quote=61280:@Sam Rowlands]If everything adheres to the second mechanism then yes it’ll work, but if a third party component still uses hard coded translations, then the user will still get localizations weather they want it or not.
[/quote]
Yes - quietly
[quote=61280:@Sam Rowlands]Perhaps a possible solution is to reduce it to one method for localization?
[/quote]
There is ONE - localized strings
How you GET the localized strings can vary
[quote=61280:@Sam Rowlands]
Currently stripping the language folders via App Wrapper Mini is not possible, it’s only possible in App Wrapper because App Wrapper actually has access to the application, where as Mini creates a Xojo Script. I will consider this for the future.[/quote]
Yeah its not possible that way either
IDE scripts dont have access to the specific instances of localized strings - they have access to the constant but not the individual localized values
There’s an FR for that somewhere
Long term the IDE probably needs some way for you to be able to see, at a glance, what localizations exist in your app and a way to set a flag that says “include these when you compile”
I don’t think it’d be nice to have it as a dialog as that could get really unwieldily and if you had to answer that on every compile annoying as heck (or if you were trying to script rebuild a few hundred demo apps like I know people do)
Some shared build setting or something maybe
At this point in time the way I see to avoid Albin’s problem is for MacOSLIb (& possibly other third party libraries that have strings in them like this) to provide “the code” and NO localized values (but the constants still have to be marked as dynamic)
This is pretty easy
Open project - export localized values to lingua
Remove from project
Now when you drop the lingua file on the IDE again those localized strings rapidly get added back to everything that still exists
(if you removed a constant it won’t go add it back in)
The idea I came up with during brunch, after a quick read of your response, is as follows. Bear in mind, I’m not trying to say how things need to be done, it’s just my suggestion on how I think this would be easier for us developers.
Use Lingua files only as means of localization, no longer allow explicit translations directly in the constants. Then at build time, convert the files into the relevant platform language files. Allowing of course a means for the developer to enable and disable specific languages.
I realize that this would cause confusion for existing projects that use hard coded translations, but maybe there could be a way around this.
I am currently struggling with this exact problem (MacOSLib “supporting” unsupported languages). What are the exact steps to remove those localized strings from MacOSLib? I’m having a hard time finding them.
I made a script to remove the language files from the built apps resource folder after build.
I can post it later if you want it. I’m on my phone at the moment
That’d be great!
Here’s the Xojo_script to remove unwanted .lproj files.
Add it after the build step but before a code signing script (AWM script or similar) if you have one.
(Use it with care and try it out on a test project first as it has an “rm -r” call. Could probably be re-witten not to.)
Parts of it is written by Sam Rowlands, thank you!
Dim appResources as String
Dim i as Integer
Dim langArr() as String
// Get the app path
appResources = currentBuildLocation + "/" + shellEncode(currentBuildAppName) + ".app/Contents/Resources/"
'<--
// Add the languages to the array that are to be deleted.
langArr = Array("bn.lproj", "de.lproj", "fr.lproj", "he.lproj", "it.lproj", "ja.lproj" ,"nl.lproj", "ro.lproj", "sv.lproj")
For i = 0 to Ubound(langArr)
Call shellExec("rm -r " + appResources + langArr(i))
Next
'<--
// The following function is created by Sam Rowlands. Kudos!
Function shellEncode(inValue as String) as String
Dim rvalue as String = replaceAll(inValue, " ", "\\ ")
rvalue = replaceAll( rvalue, "&", "\\&" )
rvalue = replaceAll( rvalue, "-", "\\-" )
rvalue = replaceAll( rvalue, "(", "\\(" )
rvalue = replaceAll( rvalue, ")", "\\)" )
return rvalue
End Function
'<--
// The following function is created by Sam Rowlands. Kudos!
Function shellExec(cmd as String) as Boolean
Dim results as string = DoShellCommand(cmd)
If results <> "" Then
Call showDialog("Error", results, "OK", "", "", 0)
Return False
Else
Return True
End if
End Function
'<--