What I have seen in translation plugins (qTranslate, WPML, Multilingual Press) are two approaches.
One is qTranslate’s (and the defunct xLanguage): use one field (one for title, other for content, etc) to hold all translations. And then, in the front end, decode its output according to the actual language.
<!--en-->English<--:--><!--es-->Español<--:-->
In the back end, the plugin decodes/encodes this in different input fields. They behave as separate entities but are a single one in the database. Whenever needed, the notation [:en]English[:es]Español can be applied directly by the user.
I’m mentioning it for the sake of documentation, but this approach is complicated, problematic and the plugin fate looms.
And then, WPML and MultilingualPress: use different fields, posts, sites, for each language and link them together.
In a theme/plugin options page it would mean two fields: page_404_en and page_404_es.
Grabbing qTrans interface idea for the_content:
create CSS/jQuery display tabs, English | Español and show one field in each.
In the frontend, detect the language and display the correspondent field:
$language = get_cookie_language(); // fake function
$the_text = get_option( 'page_404_' . $language );