Hide Languages I'll Never Use?

I internationalize my apps into English and Spanish, with occasional French, German, and Portuguese as well. I’ll never support languages such as Assamese, Gujarati, Kannada, Tigrinya, etc… but I have to scroll through them ALL when I’m adding dynamic constants. This is wasting a lot of my time.

Is there a safe place (in the Xojo application bundle, I presume - there is no pref for this) I can go to alter what languages show up in the language drop-down when defining constants? I will never need more than 5… no need to have several screens worth show up to scroll through…


– Kimball

There isn’t

That stinks. :wink:


Yeah that ones been on the wish list for a VERY long time :stuck_out_tongue:
Notice the case I said blocks it - I submitted that one just under a year after starting here :stuck_out_tongue:

Hmm… I’m looking in Feedback at my case linked above - and I don’t see any other cases that block it… Am I doing something wrong?

I’m telling you to look at something you can’t see :stuck_out_tongue:
See case 6250

Ah. So in other words, my request ain’t gonna happen anytime soon, because the entire localization end of things has to be gutted / rethought.


Well it needs to be redone to provide better localization support - period.
And when it’s done & done we’ll include something like what you’re asking for (well we’ll at least consider it)
Right now your request would be kind of hard to accommodate on its own & supporting localizations better in general so you can have something like Portuguese as spoken in Portugal vs Portuguese spoken in Brazil is hard to do today as the list really only recognizes on variation.
But in many cases there are a number of variants - French is a good example.
There should be french as spoken in france, as spoken in canada (quebec) and as spoken in other places around the world.
But there isn’t - so you get “French” which is correct for some but not others

I’m on iPad and can’t test, but what if you export localizable value you want to add, as if you wanted to localize it with Lingua, and re-import them?
I don’t know what happen when re-import empty localizable file.

You could add a localization after the fact without breaking the signature BUT that won’t work forever
You don’t even need to export them (since in a built application there is nothing to export)
You open the app bundle on OS X - navigate to Resource & create a new .lproj with the new strings (but there are a LOT esp for the IDE)

But with how Apple is suggesting people sign their executables with upcoming tools this action would break the signature.

And we really should be able to do this in the IDE itself.

My workflow is not one that lends itself well to what Thomas suggests - because I build my UI on the fly. For instance, today I’m building a simple user management system, so I’ve created a container control with a listbox to list users and some buttons to perform actions on those users. So I throw a button on the panel, then it’s time to caption it… this will be the “Delete User” button, so I add #DELETE_USER as the caption, then have to go create a string constant with name DELETE_USER, add a default value of “Delete User”, make it dynamic, then add an English and Spanish value for it. I don’t know what strings I’ll be adding ahead of time, as I only have a general set of requirements to work from - i.e., I’ve been told to add a simple user management feature that allows the editing of usernames and passwords.

If I had all the strings ahead of time, round-tripping it would make sense, but as I build stuff on the fly, I’m identifying pain points in the UI that I wish could change - thus my request.

When I add a feature which need to be located, I duplicate an existing localized value and rename it (and localize it). So I don’t have to search each country.

@Thomas ROBISSON - that’s a possibly viable alternative. I’ll switch to trying that to see if it helps cut down on the time.