Great question! I have the same exact issue; my constants are essentially: what languages are supported in my applications, and additional information about those languages as they pertain to functionality in the app.
Unfortunately, the best thing I've found (as you have) is to simply redefine constants for each language, as you are currently doing (I know, you definitely wanted to hear that).
Obviously it feels wrong because it's the opposite of DRY (WET??). However, constants should change so infrequently that the 5-10 minutes of redefining them for each language does not really bother me. At the end of the day, small issues with some 'elegant' solution like shared config or code generation could take hours or days to resolve, so what is really gained? Added complexity with the risk of something going wrong that could take additional effort to fix is not something that I want to deal with.
Furthermore, if your application has so many constants that redefining them per language when you add or change them takes a significant amount of time, you might just have a more significant code smell to deal with and, at that point, you may want to turn to something more complex.
So in short, redefining them for each language has been my best solution, and I have yet to think of anything more DRY that wouldn't have more risk factor than I want to deal with.
One thing to definitely do, though, is to ensure that your constants are well documented in a generalized (and language agnostic) manner (we have a company documentarion repo with specs, miscellaneous docs, 'drawing board' docs, etc. where we keep this document). Also make sure you have mechanism(s) in place to keep their definitions in sync. That's about as big a problem with the duplication approach as you'll have, except for a small amount of psychological distress from intentional code duplication. But in the end, your constant changes should be very deliberate and infrequent, so synchronicity issues should be essentially nil.
I should also mention that over the years, I've seen multi-language ports of various libraries (too tired to remember what they are at the moment) written by the same group that invariably have constants defined in the languages themselves. No shared config, no code generation (except for Google API client libraries... but come on, Google has the resources to afford such complexity). So I think we've hit a brick wall on this one. Maybe someone will eventually come up with a library to deal with this problem ;)
type
attribute for structure identification when transferring it across the wire. Having this, the mobile clients define only constants (types) they understand at the moment of the time and ignore any unknown types. Dynamic definition would cause a lot of problems.