AFAIK the current display language isn't exposed via any form-accessible metadata, nor a special custom XPath function, such that you could immediately use it in a relevant expression for your desired purpose [that said, either of these might make for an interesting future feature proposal... 
]
However, with a little creativity you can accomplish much the same yourself.
In the following form, I use a jr:choice-name() function to get the translated label for a select question. Because I dont actually want to display this question I always hide it with a relevant=false. For the translated label of the (sole) option for this select I put in the language identifier; in this way, the build-in translation apparatus will give me back the current selected language id! 
The only complication is getting this to be recalculated appropriately, since changing the language option does not automatically trigger form re-calculations, alas. So instead, I explicitly trigger recalculating the language whenever a specific initial required question is changed (ie name). [if you dont do this, you are stuck with the default initial language, because the language calculation never gets recalculated until you do the final submit, which is too late]. Once you have the language identifier you can, as you suggest, use it in relevant calculations to show/hide different language-dependent form content.
Have a play with this form and see if you can adapt it to your needs:
GetLanguage.xlsx (18.9 KB)
Caveat: you must go back and change the value of the triggering question if you subsequently change your language selection, for language to be recalculated.
[looking back, this appears similiar/same to an approach suggested previously by @danbjoseph ]