See, that is precisely one of the problems that the
translation plugin sidesteps completely. You don't need to set up anything server or client side that the client browser has to "remember". And using completely different pages has some minor benefits, such as the possibility of using templates for them.
If maintaining
whole different namespaces is an issue, you could modify the plugin slightly so that instead of using translation namespaces it uses translation subpages only, like what the Fedora Wiki does. Thus pages would become, say,
:mycontent:en[/m] and [m]mycontent:de[/m] with the required per-language content, and their parent page [m]:mycontent only contains the labguage-selection code and calls the above pages via the Include Plugin:
<ifvar lang=en>
{{page>.:en}}
<else>
{{page>.:de}}
</ifvar>
(Or even better, if this is somehow possible:)
{{page>.:{{var>lang?lang:de}}}}
This is a possible setup. Or you can make one language the default in
:mycontent and only subpage the other as required. That's another possible setup.
Anyway, in order to add the language to the query string
in every page call, which is what the above solution would require, you would have to create an action plugin that reads, maintains and changes the needed attributes in the
$_GET[/m] and [m]$_SERVER variables. This could be via a cookie or by adding the information to the rendered page's meta, for example.