Double Length Pseudolanguage and Non-localized string on device

It's just meant to be a stress test, and I think it's hit/miss when targetting a device, so in this this case, you may need to settle for sim testing only.

Thanks Quinn and KMT. I understand the problem better now. I was trying to build the application using command line and install it using over the air installation or manually using iTunes. Since I was specifying these parameters inside a scheme and I was building a scheme I assumed that these parameters will be available when I install and run the application on device. But it is not the case since these parameters are environment variables injected by Xcode.

I was trying to setup a pseduo locale testing build (combination of Double Length Pseudolanguage and Show non-localized strings) on my Jenkins CI that my QA team can use to test different localization issues such as layouts, missing strings etc. And hence I was trying to build from command line and not via Xcode. But I guess that there is no way to enable these parameters when running application outside of Xcode.

Regards,

Bhavik

But I guess that there is no way to enable these parameters when running application outside of Xcode.

You can do this if you’re prepared to build your app differently. The basic strategy is:

1. Run your app from Xcode with the debug options you want.

2. In your app, dump the environment variables that got set by Xcode. You can use the standard C

   environ

   global variable for this.

3. Modify your app so that, right at the start of

   main

   , you set those same environment variables using

   setenv

   .

There’s two things to watch out for:

• You must set the environment variables before anything uses Foundation. For most apps the start of

  main

  is fine. However, if your app has code that runs at load time (the most common examples are C++ static initialises and framework init functions), things get trickier.

• In many cases these environment variables are not documented API. It’s fine to use this approach as part of a debug build you ship to testers, but don’t use it for code you distribute to users.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks Quinn for the reply. I would use a bow emoticon if there was one. 🙂

Regards,

Bhavik

I have the same issue- but I need/want to be able to send a debug build out via TestFlight. XCode has no ability to use/create an imaginary language. So for example I can't use Klingon for a test language, or insert my own .strings file for a language that show "**KEYNAME**" for a strings key, instead of the actual translated phrase. My translation team is asking for this kind of functionality (we are a global company). We can make sure all the layouts are properly translated this way.

We have added some debug code to override the system language (it's a little hacky, sure) but with it we could debug all of our strings easily, if there was a way to even include a fake language. But we cannot.

I realize this is a bug report, but wanted to add my comment to this topic.

I’m a bit confused as to what you’re trying to do here. If you’re trying to engage the double length pseudolanguage mode in a TestFlight build, I recommend you try the the approach I outlined in my post of 28 Dec. OTOH, if you just want to create a dummy localisation that happens to be very long, it seems like you could do that by picking an obscure language (one that none of your testers use) and putting your dummy localisation there.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"