Both multilingual data and user permissions can quickly become complex. Here are some options that might fit with your workflow:
Polylang historically has worked well with graphically configured custom data plugins, such as Pods. This might be a good fit.
Loco Translate can be useful for changing translations when WordPress core internationalization functions are used.
At a more foundational level display of a field across many languages depends on how the desired language is tracked.
WordPress multisite is sometimes used for tracking multi-lingual content, where each site can be detected by blog ID, path, subdomain, or can have completely separate URLs. User permissions also comes along with this, where users can be given author or editor roles for individual sites within the network.
Within a single site, one might track the current language with a URL paramter, such as ?lang=en, where that value would then be accessible in PHP as $_GET['lang'], or one might set a cookie based on other URL structures, buttons, user actions, or by detecting the default language of the browser or country of origin for the requesting user.
Having “only one permission,” such as editing one field, can get tricky. The easiest solution is to make a frontend page, such as with [pods form="1"] shortcode, so then user permissions can be limited to that page, separate from wp-admin.
Within wp-admin, there is a user capabilities and user roles field for Permissions in each field’s advanced options within Pods. The trick is that one would have to define all the things the user *cannot* edit to have a permissions configuration where only one field were editable.
Another broad by applicable route to permissions within wp-admin, in addition to per-field capabilities, is to hide menu items with CSS and restrict wp-admin pages by URL. This requires a mix of approaches, such as redirecting the user to the desired page at login, plugins such as LoginWP can do this, or redirecting the user if any URL in wp-admin is accessed other than the desired page: this requires a bit of custom programming such as on the admin_init or admin_menu hooks. If one wants an installation to be especially hardened, one would also need to filter requests to wp-admin/admin-ajax.php or /wp-json/ to make sure saves and other queries are not possible without appropriate authentication. The complexity of combining all these approaches is why a custom frontend field is often simpler.
There are many plugins for editing WordPress users and capabilities, which are the formal system WordPress uses to define what a user is allowed to do. These can be assigned, or new permissions defined for use with the Pods capabilities fields or functions like current_user_can() with Pods Admin > Components > Roles & Capabilities.
