Apex multilingual applications and build options

Always check out the original article at http://www.oraclequirks.com for latest comments, fixes and updates.

Just a quick reminder for those who are devoloping Apex multilingual applications:

Build options' state is propagated to translated applications at the time of seeding, so you need to be careful when changing the state of a build option in the primary language because you may end up with translated applications having a different build option state.

For example, say you have a "production" build option attached to an application process whose goal is to run some PL/SQL code only if the application is deployed in the production environment.
Of course at some point during development you need to verify it it works so you turn on the build option (state = "include"). You seed and publish your mapped applications in order to verify if it works also when the user changes language. Then you turn off the build option (state="exclude") but you forget to seed and publish again the translated applications.
The result is you end up with a mixed situation with the primary application having "production" off and translated applications with "production" on (or viceversa) and you are probably starting to see some odd behaviour when you change language.
Even worse if you seed and publish a subset of translated applications, the situation may become really confusing.

The rule of thumb when you change a build option's state in a multilingual application is to always seed and publish immediately all translated applications for consistency.

At any rate, you can quickly assess build option states for all the translated applications by running the following query as the schema owner (or sysdba):

select application_id, build_option_name, build_option_status 
  from apex_application_build_options
 where application_id in (select b.translated_application_id 
                            from apex_application_trans_map b 
                           where b.primary_application_id = :APPLICATION_ID
                             and b.workspace = :WORKSPACE)
    or application_id = :APPLICATION_ID
 order by build_option_name, application_id;

100 production Include
134 production Include
144 production Include 

I am not quite sure if this should be regarded more as a feature or as a problem, I could not really figure out a situation where you might actually desire to have a primary application whose build options' state needs to be different from the state of its translated counterparts.