Camera and photo-picker localization sits at the boundary between language, privacy and a user’s personal media. A product may ask for camera access, open a system photo picker, show a limited-library permission, capture a new image, select several existing images, crop a photo, attach a video or upload media in the background. Searches for camera localization, photo picker localization, media library translation, photo permission localization, image upload localization and multilingual camera UI all describe a flow where a small wording error can make users misunderstand what the app can see or what they are about to share.
Good localization preserves three boundaries at once: permission, selection and transfer. Granting an app permission to use the camera is not the same as selecting one photo. Selecting one photo is not the same as uploading the whole library. Allowing access to selected photos is not the same as allowing full-library access. A translation that blurs these boundaries can make a privacy-respecting flow sound invasive, or make a broad permission sound narrower than it really is.
This guide explains how to localize camera capture, photo pickers, gallery and media-library access without changing what users grant, select, edit or upload. It covers camera permissions, microphone access for video, system pickers, limited-library access, capture states, image orientation, metadata, file size, live photos, videos, multiple selection, cropping, editing, upload progress, background transfer, privacy, accessibility, error recovery and the release question that matters most: would a target-language user understand exactly which media is being accessed and what will happen to it next?
This article belongs to eduKateSG’s Master Art of Translation architecture. It complements the established guides for permission prompts and privacy choices, file uploads and attachments and device pairing while owning the specific human journey around cameras, personal media and selected visual files.
Quick answer: keep permission, selection and upload as separate concepts
A safe multilingual camera or photo flow starts by asking what the app is actually doing. Is it requesting permission to use hardware? Is it invoking a system picker that returns only user-selected items? Is it asking for broader library access? Is it capturing new media? Is it transferring selected media to a server? Each step needs its own vocabulary, because users make different trust decisions at each step.
- Permission: say what capability or collection the app is asking to access.
- Selection: say which items the user has chosen and how many.
- Capture: distinguish taking a new photo or video from choosing an existing one.
- Edit: explain crop, rotate, trim, compress and other transformations separately from selection.
- Transfer: distinguish local selection from upload, sync, send or publish.
- Verify: test the exact operating-system permission and picker states in every target locale.
1. Begin with the user journey, not the string list
Camera and media flows are usually distributed across several surfaces: application UI, operating-system prompts, native pickers, device hardware, background upload and later media-management screens. A translation spreadsheet can make these strings look unrelated even though the user experiences them as one sequence.
Map the journey first. A typical flow might be: tap Add photo, choose Take photo or Choose from library, encounter a system permission prompt, capture or select media, review it, edit it, confirm it and upload it. Each stage has a different object and a different level of commitment. Localize the transitions so the user always knows which stage they are in.
Verification: run the complete target-language journey on a physical device rather than reviewing screenshots independently.
2. Distinguish camera access from photo-library access
The camera is a hardware capability for capturing new media. The photo library or media collection contains existing personal files. A user may be comfortable granting one and not the other. Translation should never use one generic term that makes the two permissions sound equivalent.
“Allow camera access” should clearly describe capture. “Allow access to photos” should clearly describe existing media. If the product asks for both during video capture because it also needs microphone access, that should be explained separately. Privacy understanding improves when each permission has a reason that matches the feature the user just invoked.
Verification: deny camera permission but allow media access, then reverse the permissions and confirm the target-language recovery text remains accurate in both cases.
3. Treat system photo pickers as selection tools, not broad permissions
Modern platforms may offer system-managed photo pickers that let users choose specific media without giving the app unrestricted access to the whole library. If the product uses such a picker, application copy should not imply that the app is browsing every photo.
The safest wording focuses on selection: “Choose photos to add” or “Select a video”. Avoid language equivalent to “Give us access to your gallery” when the app receives only the chosen items. The technical privacy model should control the wording, not a legacy phrase reused from older full-library permission flows.
Verification: inspect what data the app actually receives after the user selects one item and compare that with the promise made in the localized copy.
4. Preserve limited-library access as a distinct state
Some operating systems allow users to grant an app access to selected photos rather than the entire library. This state is neither “denied” nor “full access”. It deserves its own terminology because the app may function normally for some items while being unable to see others.
Localized settings might say “Selected photos only” rather than simply “Allowed”. If the user tries to choose an inaccessible photo through an app-managed browser, the product may need to explain how to add more items to the allowed set. Do not translate the state as partial failure when it is an intentional privacy choice.
Verification: grant access to two photos, then attempt to select a third and observe whether the target-language explanation reflects the limited scope correctly.
5. Explain why a permission is needed at the moment of use
Users understand permission requests better when the request follows a clear action. A camera prompt that appears immediately after tapping Take photo has obvious context. The same prompt appearing during app launch may feel unrelated or invasive.
Localization should preserve that contextual link. “Allow camera access so you can take a profile photo” is stronger than a generic “Camera required.” The sentence identifies the capability, the reason and the feature. Avoid overclaiming that the app “needs” broad access when a narrower alternative exists.
Verification: read the localized rationale without looking at the screen and ask whether a user could infer the feature that triggered it.
6. Keep permission denial separate from feature failure
If the camera cannot open because permission was denied, the camera itself may be working perfectly. Error language should identify the access condition rather than implying broken hardware or a defective app.
“Camera access is off” is more accurate than “Camera unavailable” when permission is the cause. If the platform requires the user to change permission in system settings after a permanent denial, the target-language recovery path should say that clearly. If permission can be requested again in-app, do not send users unnecessarily to settings.
Verification: test first denial, repeated denial and permanently denied states because platforms may present different recovery options.
7. Distinguish camera unavailable from camera in use
Camera failure can have several causes: permission denied, hardware unavailable, another app using the camera, device policy restrictions, missing camera hardware or temporary operating-system conditions. Translation should not flatten these into one vague error when the product can identify the cause.
A supportable message names what is known and avoids guessing what is not. “Another app may be using the camera” is different from “Camera access is blocked by your device settings.” If the system cannot determine the cause, use an appropriately general message rather than a false diagnosis.
Verification: reproduce at least permission denial, no-camera simulator state and another-app contention where the platform supports it.
8. Separate photo capture from video capture
Photo and video modes may share the same camera view but differ in storage, duration, microphone use, file size and later editing. A target language should make the current mode obvious before the user presses the shutter or record control.
Video capture can require microphone permission even if photo capture does not. If the product asks for microphone access, the rationale should connect it to audio recording rather than to the camera generally. When audio is optional, say so; when silent video is supported, do not imply microphone denial blocks all video capture unless that is true.
Verification: deny microphone permission while allowing camera access and verify that the target-language behavior matches the actual capabilities that remain.
9. Localize shutter, record and stop controls by action
Icons reduce text, but accessible names and tooltips still need precise verbs. Take photo, start recording, pause recording and stop recording are different actions. A single target verb equivalent to “capture” may be too broad if it hides whether recording begins or ends.
For screen readers, the action name should reflect the current control state. A record button that changes to Stop should update its accessible name. If the interface allows pausing, distinguish pause from stop because one preserves the recording session while the other ends it.
Verification: navigate the capture UI with a screen reader and perform the full state change without looking at the screen.
10. Preserve front-camera and rear-camera meaning
Switch-camera controls may use labels such as front, rear, selfie or back camera. The target terminology should match the platform and avoid ambiguity with browser navigation words such as back.
Where device classes differ, physical orientation can be more reliable than colloquial labels. A tablet, foldable or external camera may not fit a simple front-versus-back mental model. The UI can keep a generic “Switch camera” action while status text names the active camera when necessary.
Verification: test the localized control on several device form factors and confirm users can predict what will happen before activating it.
11. Treat flash and torch as different capabilities
A flash fires briefly for image capture. A torch or continuous light stays on. Products sometimes use one source term casually for both, which can become confusing in languages that distinguish them more clearly.
Translate according to behavior, especially when the interface exposes Auto, On and Off for photo flash but separately allows continuous lighting in video. Do not let a target label imply continuous illumination when the control only affects capture flash.
Verification: activate each control and compare the observed hardware behavior with the target term.
12. Preserve zoom semantics
Zoom labels can represent optical zoom, digital zoom, camera switching or a combined system. A translated multiplier such as 0.5×, 1× or 2× should preserve the numeric value and multiplication sign conventions while the help text avoids promising optical quality if the implementation is digital.
Gesture instructions also need cultural and device context. “Pinch to zoom” may require an established target-language phrase rather than a literal translation of pinch. The instruction should describe the gesture users know from the platform.
Verification: perform gesture and button zoom in the target locale and confirm labels track the actual zoom level.
13. Make multiple selection explicit
A picker may support one item, several items or a product-defined maximum. “Choose photo” and “Choose photos” can require different grammar, and some languages need more than a singular/plural pair.
When there is a limit, explain it before the user invests effort in selecting too many items. Runtime copy such as “3 of 10 selected” should use locale-aware number formatting and plural rules. If videos and photos share one combined limit, say so; if they have separate limits, do not collapse them.
Verification: test zero, one, two, maximum and over-limit selection counts in every target locale.
14. Distinguish selection from confirmation
Highlighting an item in a picker does not always mean the app has received it. A confirmation action such as Add, Done or Choose may finalize the selection. Translation should preserve this two-step model when the UI uses it.
A button labeled “Upload” inside a picker can be misleading if pressing it only hands files back to the app and the actual network upload happens later. Prefer action names that match the next state. If selection immediately starts transfer, then Upload may be correct.
Verification: select an item but do not confirm. Inspect whether the app has access yet and compare that fact with the target wording.
15. Keep local media selection separate from network upload
Users often assume that choosing a photo means the photo has already been sent. In many products, selection remains local until a later Save, Send, Post or Upload action. This distinction matters for privacy, bandwidth and reversibility.
Use staged language if the workflow is staged: “1 photo selected” followed by “Upload photo”. If upload starts immediately, say “Uploading” and provide progress or a background-state explanation. Do not use “Added” ambiguously if the user cannot tell whether added means to a local draft, a message or a remote account.
Verification: disconnect the network after selection and observe whether the target-language state remains truthful.
16. Explain upload progress without confusing processing progress
Media flows often have at least two progress phases: transferring bytes and processing the received media. A photo may finish uploading but still be resizing, scanning, transcoding or generating thumbnails.
Use separate labels if the distinction affects waiting time or next actions. “Uploaded — processing” is more informative than a progress bar that jumps to 100% and then appears stuck. Video processing can be especially long, so target copy should avoid implying that transfer completion means the final asset is ready.
Verification: test a large video on a fast network so upload completes quickly but processing remains visibly active.
17. Treat background upload as a stateful process
Uploads may continue after the user leaves the screen or may pause when the app enters the background, loses network access or encounters operating-system limits. Localization should tell users what they can safely do.
“You can leave this screen; upload will continue” is a strong promise that should be used only if the product supports it reliably. Otherwise use more cautious wording. If uploads resume automatically later, distinguish Paused, Waiting for network and Retrying from Failed.
Verification: start an upload, switch apps, lock the device, disable connectivity and restore it while observing target-language state changes.
18. Preserve image orientation and rotation meaning
Photos can contain orientation metadata rather than physically rotated pixel data. A preview can look correct while an exported or processed image appears sideways if metadata is mishandled. Localization should distinguish Rotate left, Rotate right and Auto-rotate rather than treating them as generic “turn” controls.
When an app says it is “fixing orientation”, the translation should not imply content editing beyond orientation normalization. Users need to know whether the original is preserved, whether the change applies only to the current upload and whether metadata is being rewritten.
Verification: test portrait images from multiple devices and compare preview, upload and downloaded result.
19. Localize crop as a framing change, not a file deletion
Crop removes or hides areas outside a chosen frame. Some editors apply crop non-destructively; others produce a new file. The UI should not make the operation sound like deleting the original unless that is what happens.
Aspect-ratio labels such as Original, Square, 4:3 and 16:9 should remain semantically exact. Number formatting should not turn ratio punctuation into a decimal. If the product enforces a crop for profile images, explain why and show the frame rather than relying on text alone.
Verification: crop an image, cancel, save and re-edit while checking whether the target labels match destructive or non-destructive behavior.
20. Separate trim from crop for video
Video trimming changes duration; cropping changes the visible frame. A literal translation that uses one generic word for both can create serious confusion because the user may think they are removing time when they are changing geometry, or vice versa.
Use established media-editing terminology in the target language. Show start and end times for trimming and frame boundaries for cropping. If both operations are available, test labels side by side to ensure they remain distinct under narrow mobile layouts.
Verification: perform each edit independently and ask whether the target term predicts the resulting change.
21. Explain compression and quality without promising impossible equivalence
Products may compress media to reduce file size. Labels such as Original quality, High quality or Data saver can imply different trade-offs. Translation should preserve the relationship between quality, dimensions, bitrate and storage without pretending compressed output is identical to the original.
If the product reduces resolution, say so in help text. If it preserves dimensions but changes compression, use wording appropriate to that behavior. “Optimized” can be too vague when users care about print quality or evidence preservation. The safest terminology is tied to measurable output characteristics.
Verification: compare selected quality modes with actual output size and dimensions and confirm the target labels describe the trade-off honestly.
22. Treat live photos, motion photos and bursts as compound media
Some photo formats contain motion, audio or multiple frames. A picker may return a compound object, a still derivative or both. Translation should not promise that every component will be preserved unless the application supports it.
If only the still frame is uploaded, say “Upload as photo” rather than implying the motion component will remain. Burst selection can also be confusing: selecting a burst album may not mean selecting every frame. Product copy should follow the object model exposed by the platform.
Verification: select representative compound media and inspect what arrives on the server and what the target-language user was told would be sent.
23. Preserve metadata choices separately from image content
Photos may contain location, capture time, device model, orientation and other metadata. Some products strip metadata during upload; others preserve it. Privacy copy should describe the actual policy rather than using a generic promise such as “only the photo is shared” when metadata remains attached.
Location metadata deserves particular care because users may not realize it exists. If the app offers Remove location or Strip metadata, translate the control as a data action, not a visual edit. The photo can look identical while the metadata changes materially.
Verification: upload a geotagged photo and inspect server-side metadata under each privacy setting.
24. Handle HEIC, JPEG, PNG, RAW and video formats without language drift
File-format names and extensions are technical identifiers. They should not be translated, though explanatory text around them should be. If the product converts formats, the user needs to know whether conversion is automatic and whether quality or editability changes.
A message such as “HEIC will be converted to JPEG for upload” is different from “HEIC is not supported.” Likewise, RAW may be selectable but too large for a particular feature. The target language should distinguish unsupported format, unsupported combination and automatic conversion.
Verification: test each accepted and rejected media type using real files rather than renamed extensions.
25. Make file-size limits specific
A media picker may allow selection of a file that the application later rejects for size. If the limit is known in advance, tell the user early. Localize units carefully and preserve the actual threshold.
“Maximum 25 MB per video” differs from “Maximum 25 MB total”. “Up to 10 photos, 25 MB each” differs from “10 photos up to 25 MB combined.” The target sentence should make the scope of the number unmistakable. Avoid converting binary and decimal units casually unless the product explicitly does so.
Verification: test files just below, exactly at and just above each limit.
26. Localize unsupported-media errors by cause
A selected item can fail because of format, codec, duration, dimensions, file size, corruption, cloud-only availability or product policy. “Cannot upload this file” is sometimes the only safe fallback, but more specific causes reduce user frustration when they are known reliably.
Translate the cause and the next action together. “Video is longer than 5 minutes. Trim it and try again.” “Photo is stored in the cloud and could not be downloaded. Connect to the internet and retry.” The recovery instruction should match the actual path the product supports.
Verification: create one fixture for each rejection reason and confirm the target language does not reuse a misleading generic recovery action.
27. Distinguish local, cloud-only and unavailable media
A media library can show thumbnails for items whose full-resolution files are not stored locally. Selecting such an item may trigger a cloud download before the app can use it. If connectivity is poor, the user can experience delay that looks like application failure.
Useful localization can say “Downloading original from cloud storage” when the platform exposes that state. Avoid promising that the app already “has” the image before the file is available. If the item becomes unavailable because an account changed or cloud access failed, distinguish that from unsupported format.
Verification: test an offloaded or cloud-only item on slow and offline connections.
28. Preserve delete, remove and detach as different actions
Removing a selected photo from a draft should not sound like deleting the photo from the device. Detaching an upload from a post should not imply erasing the original. The verbs used in media interfaces have strong consequences.
Translate the object and scope: “Remove from message”, “Delete uploaded photo”, “Delete from device” are very different. If the application never deletes local media, avoid a target verb that users commonly associate with permanent deletion. If deletion is permanent, say so plainly.
Verification: perform each removal action and inspect local library, draft and server storage afterward.
29. Keep save-to-library separate from upload
Some apps create or edit media and then offer Save to Photos, Save to device or Download. These actions move media toward the user’s library, the opposite direction from upload. A translation that reuses “save” for both server upload and local storage can confuse ownership and location.
Use destination-aware language. “Save to device” identifies local storage. “Upload to account” identifies remote transfer. “Add to album” may mean organizational grouping rather than copying the file. The destination should be clear whenever the same media can exist in several places.
Verification: trace where the file exists before and after each localized action.
30. Localize privacy explanations around actual data handling
Camera and media features invite privacy claims, but those claims must reflect implementation. If image analysis happens on-device, say so only if it truly remains on-device. If media is uploaded for processing, do not imply local-only handling. If thumbnails are cached, know whether that matters to the privacy statement.
Translation should preserve certainty and scope. “We do not store your photos after processing” is not the same as “We do not share your photos.” “Only selected photos are uploaded” is not the same as “We cannot access other photos.” Each claim should be tied to a product fact that can be verified.
Verification: review target-language privacy strings with the same data-flow diagram used by engineering and privacy teams.
31. Test accessibility of visual media controls
Camera UIs are visually dense, but blind and low-vision users still need understandable control names, selection counts, permission states and upload results. Localization must cover accessible names even when no visible text appears on the icon.
Provide context for thumbnails: “Photo 2 of 5, selected” is more useful than “Image”. For camera controls, names should state the action, not merely the icon shape. If an image has generated alt text for later content use, keep that separate from the accessible name of the picker thumbnail itself.
Verification: complete capture, selection, removal and upload with a screen reader in the target language.
32. Test right-to-left layouts with camera chrome and previews
Camera previews themselves are not simply mirrored because the interface is right-to-left. Controls, carousels and text may mirror; captured content, orientation indicators, directional icons and before/after relationships may follow different rules.
Do not reverse media content to make the layout feel RTL unless the camera behavior requires it. Pay special attention to arrows for next, previous, rotate left and rotate right. A mirrored icon can change the physical action it communicates. Test the semantic direction of each control rather than applying one blanket mirroring rule.
Verification: compare RTL and LTR builds on a physical device and verify both layout order and actual media transformation.
33. Preserve user intent when the picker is cancelled
Cancelling a picker should normally mean no new selection is committed. It should not be translated as deleting prior selections, discarding the whole draft or cancelling an upload that already started unless the product really behaves that way.
If the picker is a modal step inside a larger flow, the target Cancel label should match platform expectations. If unsaved edits to media will be lost, a secondary confirmation can explain that specific consequence. Avoid adding warnings where cancellation is harmless because unnecessary warnings train users to ignore important ones.
Verification: cancel before selection, after selection, after editing and after transfer begins to confirm the localized action describes the correct scope.
34. Keep retry, reselect and recapture separate
When a media operation fails, the next action may be retry upload, choose a different file or take a new photo. Those actions should not share one vague button label. Retry implies the same underlying media can be attempted again; reselect implies choosing a different or newly available item; recapture implies creating new media.
The distinction matters when the failure is permanent for the chosen file. If a format is unsupported, Retry may never help. If network connectivity failed, Retry may be exactly right. Localized recovery text should be driven by cause.
Verification: map every media error to the action offered and confirm the target verb describes that action accurately.
35. Validate the whole media journey against real devices
Camera and media localization cannot be completed reliably in a browser-only string-review tool. Operating-system prompts, native pickers, hardware controls, cloud-library behavior and background transfer are all part of the real experience.
Create a device matrix that includes at least one small phone, one large phone or tablet, major platform versions you support, a right-to-left locale where relevant and representative devices with cloud-only media. Test permission first-run, denial, limited access, full access, capture, selection, editing, upload, backgrounding and recovery. Record defects as workflow defects, not merely text defects.
Verification: a target-language tester should be able to narrate what the app can access, which item was chosen and where that item goes next at every stage.
A repeatable camera and photo-picker localization workflow
- Map every step from feature entry to final media state.
- List camera, microphone and library permissions separately.
- Identify whether the product uses a system picker, broad library access or both.
- Document limited-access states and how users can add more permitted items.
- Separate capture, selection, confirmation, editing and upload terminology.
- Protect technical format names, extensions and numeric limits.
- Define how metadata, location and cloud-only media are handled.
- Translate recovery actions according to cause rather than generic failure.
- Test singular, plural and selection-count messages with runtime data.
- Test visible and accessible labels together.
- Exercise background upload and interrupted connectivity.
- Run final tests on physical devices in target locales.
Worked scenario 1: selecting one photo without full-library access
A user taps Add profile photo. The app opens the system photo picker. The user chooses one image and confirms. The app receives only that selected media item. In this flow, wording such as “Choose a photo” is accurate. A pre-emptive message saying “Allow access to your photo library” would describe a broader permission than the feature actually needs.
After selection, the app shows a crop screen. The image has not yet been uploaded. The state should say something like “Adjust photo” or “Crop photo”, not “Uploading”. When the user taps Save, the app begins network transfer. Only then should upload progress appear.
This scenario demonstrates the core model: selection is local and scoped; editing is another local action; upload is a later transfer. Preserving those boundaries helps users understand privacy and gives translators a stable semantic model.
Worked scenario 2: limited photo access and an inaccessible image
A user previously allowed the app to access three selected photos. The app displays only those three in its custom media browser. The user now wants a fourth image that is not in the allowed set. The interface should not say “No photos found” because the library contains photos; the app simply does not have permission to read them.
A better message is “You’ve allowed access to selected photos. Add more photos to choose from.” The action should follow the platform’s supported path for extending access. If the user switches to full-library permission, the target language should make clear that the scope has widened.
The translation task is not merely to find a nice word for limited. It is to preserve the privacy choice as a legitimate state rather than mislabeling it as an error.
Worked scenario 3: video upload completes but processing continues
A user selects a 400 MB video. Upload progress reaches 100%, but the server still needs to transcode the file before playback is available. If the UI says “Done” at 100%, the user may assume the video is ready and think the product is broken when playback fails.
Use phase-specific language: “Upload complete. Processing video…” followed by “Video ready.” If processing can continue in the background, explain whether the user may leave the screen. If a notification will arrive when processing finishes, say that accurately and ensure the notification uses the final authoritative state.
This separation is especially important in translation because some target languages use one broad verb equivalent to “send” or “load” for several stages. The terminology should follow the system phases, not the broadest everyday verb.
Worked scenario 4: camera denied, gallery still available
A user denies camera access but still has a working system photo picker. The Add media sheet should continue to offer Choose from library while Take photo is disabled or explains how to enable the camera. A generic banner saying “Media access denied” would incorrectly suggest both paths are unavailable.
The target language should preserve capability-specific recovery: “Camera access is off. You can still choose an existing photo.” If the product offers Open settings, the action should relate only to the blocked capability. This gives users a usable alternative without pressuring them into a broader permission than they need.
Good localization therefore protects user choice as well as technical accuracy. It explains what still works, not only what is blocked.
Release checklist for camera, photo picker and media flows
- Camera, microphone and media-library permissions have separate wording.
- System picker selection is not described as broad library access.
- Limited-library access is treated as a valid state, not simply allowed or denied.
- Permission rationales name the feature that needs access.
- Denial errors identify permission state rather than blaming hardware.
- Photo and video modes remain distinct.
- Accessible control names reflect capture state.
- Multiple-selection counts and limits use locale-aware grammar.
- Selection, confirmation and upload are not collapsed into one action.
- Upload progress is distinct from server-side media processing.
- Background upload promises match actual platform behavior.
- Crop, trim, rotate and compression use distinct terminology.
- Compound media behavior is explained accurately.
- Metadata and location handling match implementation.
- Format names and extensions remain technically exact.
- File-size limits state whether they apply per item or in total.
- Cloud-only media has distinct download and availability states.
- Remove, delete and detach preserve scope.
- Privacy claims are reviewed against real data flows.
- Physical-device testing covers permissions, picker, capture, upload and recovery.
Frequently asked questions
Does choosing a photo mean the app can see the entire library?
Not necessarily. A system photo picker can allow the user to select specific items without granting broad library access. Product copy should describe the actual access model being used.
Should “gallery” and “photo library” always be translated as the same thing?
No. Use the terminology familiar on the target platform and distinguish the operating-system media collection from an app-specific gallery when both exist. The object users are interacting with should control the term.
Is limited photo access an error?
No. It can be an intentional privacy choice. The app should explain what is available under that scope and how the user can change the selection if needed.
When should the UI say “Upload”?
When the action actually begins or commits a network transfer. If the user is merely selecting a local item, choose a verb such as Select, Choose, Add or Done according to the workflow.
Why separate upload from processing?
Because a file can finish transferring before it is ready for use. Videos may need transcoding; images may need resizing or scanning. Users make better decisions when each stage is named accurately.
Should metadata removal be described as editing the photo?
Usually it is clearer to describe it as removing metadata or location information. The visible pixels may remain unchanged even though attached data is removed.
What is the safest way to translate camera permission recovery?
Describe the current permission state and the actual next step supported by the platform. Do not send users to system settings if the permission can still be requested in-app, and do not promise another prompt if the platform will no longer show one.
What should be tested first?
Start with the complete permission-and-selection journey on a physical device: first use, allow, deny, limited access, choose one item, choose several, cancel, edit, upload, background the app and recover from an interrupted transfer. That sequence exposes more real localization risk than isolated screenshots.
Final principle: personal media requires precise language
Camera and photo flows feel simple because users perform them every day, but they combine hardware, private data, operating-system permissions, file formats, editing, transfer and storage. The words surrounding those actions tell users what the product can see and what the product is about to do.
Professional localization preserves the boundaries. A permission is not a selection. A selection is not an upload. An upload is not processing. Removing an attachment is not deleting the original. When those distinctions survive naturally in the target language, users can make informed choices without reading technical documentation. That is the standard a trustworthy multilingual media flow should meet.