Geep

I dunno, but looking at the TDM Script Reference, there's a few things you might try from a triggered script. Like <entity>.stopSound(channel), where channel might be SND_CHANNEL_ANY. Don't know if this works with AI. Or maybe <ai>.bark(sound), where sound could be a short silence clip. Or even just null? Other possibilities I guess: <emitter>.Off(); <emitter>.On(); startSound(...); playAndLipSync(...);

If the automation could do a screenshot, that would be another approach. You'd puppet to each target, frob it, take the screenshot (and in the case of my custom readables, wait some seconds and screenshot again). Then review the translations from the screenshots. Would be even better if it was possible for the script to pass a meaningful filename for each screenshot.

Google will give it away with "Famous Slovakian building from 1505"

This is an invitation for anyone fluent in a non-English but TDM-supported language to review in the next 4-5 weeks how well AI LLM did in translating a small mission into your language. Details and link just posted at... Thanks!

Interesting, and maybe worthwhile to develop something like this for larger missions than Away 1: Air Pocket. In practice you'd want a much longer pause than 3 seconds to do a careful analysis of a translation. Or some way to pause indefinitely at each stop, then signal to resume... can the automation do that? While at a stop, you might want to switch back and forth between English and your language (that my custom Air Pocket readables allow). For a long mission, you could probably accomplish much if the FM author just provided a doc with an ordered list of teleport targets and what to do or check at each stop. This could include stops whose sole purpose was to trigger something. Mechanical-puzzle solving might still be an issue.

I might add, DR-TDM sync didn't appeal to me is that it seems to need a 2-monitor setup. I've prioritized a tiny PC dev box that I can easily backpack, but it can't really handle 2 monitors. Maybe rethink that in the future.

@datiswous, all good points. I did use teleport in that manner extensively when developing and testing Away0: Stolen Heart, as well as layers. I haven't used the DR-TDM sync technique. One difficulty I foresaw for the current endeavor, when testing translations of Messages and Objectives, is there were various triggers, conditions, and sequence dependencies. So my pseudoFM really stripped all that away.

That's all true, there's no automatic text flow between pages in TDM. With Air Pocket (for which I hope to release the i18n beta next week), the text Briefing upon inspection did need an extra page for some languages. Fortunately, since the Briefing comes at the very start, the inspection didn't take much time. For the readables, I used scaling, so no extra pages. But still inspection. And particularly for popup messages, because they occurred later in the FM, I hand-made a pseudoFM with just those assets, so I could get to them fast. Still a lot of pain for the gain. It's unfortunate that the support for translation in DR is so weak.

I used the AirPocket all.lang to roundtrip test rebuild_all_lang version 1.1. The latter is confirmed to work, including for the previously-failing Romanian. (Built-in Windows support relies on a library that doesn't cover ISO-8859-16.) There's a bit of trickiness to this roundtrip business, because, in order to do a file comparison (using fc /t), you have to strip most comments from both the source and rebuilt all.lang. Also, the language blocks are in different orders. And the way gen_lang programs work, if a translated string is not provided in a particular language block, the english content is substituted. The latter in rebuild will be propagated back into the language block, where it didn't exist in the original. So editing fixup needed before comparison. Further problems with trailing whitespace, and spaces getting substituted for tabs. Whew.

Thanks for the details. Clearly from what you report, some sequences of your actions can make it act funny - in both the haha and weird sense. I think you should be able to do stuff on the inn's ground floor without causing problems upstairs, but once you start to climb the stairs, there are triggers involved. It now occurs to me too that you can adjust the game's overall frob distance with a cvar, and (since I never tested for that) that could mess up some aspects. For now, I'm so glad you were able to find ways to get it to work as intended.

I'm sorry this didn't work for you. As @datiswous mentioned, it might have to do with the route you took, or where you stand when the door is open, and whether that route or position bypasses triggers (or conversely triggers prematurely). I recall there were also issues about how many frobable items could be on the platter and close to each other. I did try to improve all that, but I guess couldn't make it bulletproof. If it's easy for you to make a short video of this behavior, I could take a look at it, see if I can reproduce it.

To summarize the various findings regarding character-level problems and their workarounds - Recommended Platform The 2024 improvements in character coverage of Stone 24pt were not distributed with TDM 2.13, but now in TDM 2.14. So the Air Pocket update's i18n will work best wtih 2.14. Mapping Error Fixed [Romanian] Due to an old romanian.map error, the Romanian character ș was rendered as Ș. Reported & fixed in bugtracker 6661, committed to dev 2.14 Rev 17437 build. Special (hacked) handling of readables in Air Pocket, to ovecome the shortcomings of mainly-ASCII fonts A system has been proposed to show the text first in English (where font is fine) and then (when current language is not English) switch over to the current language, but in the Stone font, which [at least for 24pt body font] has all 256 characters. This would require new C++functionality, not yet developed. In the meantime, the workaround implementation is to embed a copy of the English text (without #str_) within custom readable sheet GUIs. Specifically for Air Pocket, the fonts and scalings used are as follows. For pg1... Mac Humaine [with English title and body textscales of 0.40 and .31, both invoking 48pt]. Stone [with non-English title and body textscales of 0.30 and 0.23, respectively invoking 48pt and 24pt]. For pg2... Shoppinglist [with English title and body textscales of 1.0 and 0.5, both invoking 48pt]. Stone [with non-English title and body textscales of 0.52 and 0.26, respectively invoking 48pt and 24pt]. For more about this, besides earlier in this topic, see bugtracker proposal "0006638: Feature request: Provide Minimal Engine Support for Fade-In Translations in Readables". For planned improvements to Stone 48pt (as well as Carleton 24pt), see bugtracter 6656, 6657. Changes to English mission_briefing.xd Some pg_1 and pg_2 sentences are slightly altered from airpocket 1.0, to generate more-valid translations. And pg_3 is introduced, to handle language overflows. Unsupported characters in the TDM Char Map [Spanish] Can't do leading "¡", so drop it and replace trailing "!" with "." Missing characters in the Font used for Briefing & Objectives, Carleton 24pt The correct full translation is retained in all.lang as a comment, but the real text has the missing character substituted by its base character without accent. Specifically: [Polish] character ń (0x9c in TDM charmap) --> n [Danish] charactera å (0xe5 in TDM charmap) --> a [Romanian] characters ș and ț (0x9d & 0x9e in TMD charmap; and probably not upper case versions either) --> s and t, S and T. Wrong-sized character in the the Font used for Briefing & Objectives, Carleton 24pt [German] lower-case "ß" (Eszett) is shown with upper case height. Left as is in Air Pocket (although replacement with "ss" would also be OK). Needs a system-level font fix, e.g., down-scaling in the DAT file. Missing characters in the Font used for Messages (tdm_message_no_art), Stone 48pt [Polish] character ń (0x9c in TDM charmap) --> n Missing characters in the Font used for Title of Stone Readables, Stone 48pt Because under TDM 2.13/2.14, Romanian character ț is not available in Stone 48pt, (used in title), only Stone 24pt (used in body) , we do a work-around, namely, suppress use of title. (Other chars also missing from Stone 48pt: ș, Ș, T+hook.

@covert_caedes, besides your interest last summer (and I'm glad you liked it), I was asked recently if there's going to be an Away2. I haven't decided yet in the long run. It won't be a 2026 project, tho.

The Air Pocket update is essentially done except for packaging. However, it was noted that a few characters were shown as missing characters, which led to the discovery for me that the updates to Stone 24pt, that I thought had been incorporated into TDM 2.13, was not. They are reportedly in the TDM 2.14[alpha], so I need to look into that. Also, I built a small utility program that will draft a rebuild of a missing all.lang file from *.lang files. See the wiki: Rebuild all lang Program. EDIT: Sorry, round-trip testing shows "rebuild_all_lang" fails. I marked the wiki as such. Will rethink implementation. EDIT2: Version 1.1 of rebuild_all_lang released; see wiki page. Romanian was failing due to missing encoding support; internals revised and custom code added... all good now.

An update. Like the Briefing, the Objectives menu relies on the Carleton 24pt font. Characters missing from this font, affecting the Romanian and Polish renderings, were mentioned a week ago. Also missing is the "a with ring above" character (0xe5 in the TDM map), affecting the Danish rendering. I've decided in all these cases to leave the full translation in "all.lang" as a comment, and provide in-game text with the base characters as replacements. Also in this font, the German lower-case "ß" (Eszett) (0xDF in iso-8859-1) is present in TDM's charmap at that point, but the provided glyph is full-height. The height should be that of other lower-case characters... it needs to be scaled down in the font's DAT file. (This font's lower-case characters appear as scaled down upper case. So this is in keeping with that.) Note: Recall the Objectives text size is adjustable using the HUD settings. Fortunately, it's set to a maximum size by default (a slider value of 1.0 applied to a base textscale value of 0.27). So, it would seem this is not an additional source of overflow worry for us. Marching through the languages continues.

The remaining task is to inspect the language strings associated with messages and objectives as they might appear in the game. However, to actually run AirPocket to completion for each of the 16 languages would be time-consuming and tedious. So, as an alternative, a minimal FM "testAirPocketMessages" was created. This was built from a clone of last year's "testSubtitlesANSI", with the subtitle assets removed, AirPocket's i18n string assets added, and the script file rewritten for a new purpose. For messages, for a given language, this allows all 7 to be reviewed one after another by simply pressing a button. The test FM and Air Pocket use the same message GUI (namely "atdm_gui_message_no_art"), showing white text on a transparent background, with vertical centering controlled by a nominal "lines" spawnarg. (While this could have been done by copying the 7 gui message objects from one Dark Radiant instance to another, I did it by searching airpocket.map for "gui_message" and copying blocks to the test .map. With object origin and entity # changes. Also, when you show a message, a supplemental message box appears in the upper left corner with #str and "lines" values. Implementation of latter is only quick & dirty.) When inspecting, mainly I will be looking for any cases where there's so much text that it overflows below the lower edge of the screen. Plus any missing characters. Also, I dimmed ambient_world, which was too blazing bright in testSubtitlesANSI. I can read overlays much easier now. (Testing within testAirPocketMessages neglects any visibility issues due to the likely background in the real game's scene.) For Air Pocket's 12 Objectives, they are copied into the test FM and altered so that they always appear. (Again, searching airpocket.map, this time for blocks mentioning "objective".) Each objective is made visible and attributes made identical (except "obj...desc" #str text) , e.g., with obj 1 as the example: "obj1_1_irreversible" "0" "obj1_1_not" "0" "obj1_1_player_responsible" "0" "obj1_1_state" "0" "obj1_1_type" "custom" "obj1_desc" "#str_fm_map_obj01_no_hurt_or_loot_crew" "obj1_irreversible" "0" "obj1_mandatory" "1" "obj1_ongoing" "0" "obj1_state" "0" "obj1_visible" "1" For test purposes, really only the last attribute is essential. TDM's GUI used for the Objectives menu limits each to 3 lines as rendered, after which it truncates the string. So that's the main thing to inspect for. (Interestingly, the last objective fails this test in English. I guess since I separately programmed a popup message that states the new objective, I never tested what it looks like in the Objectives list.) Next, I'll use all this to review the language strings.

OK, the Briefings are essentially done. As I said before, content is now distributed into 3 pages, instead of the original 2. Also, I’ve been using “\n\n” to separate paragraphs. This provides “air” between paragraphs, and also makes it easy to fit yet more text on a given page if necessary by combining paragraphs. I needed to that only once (for German). There are additional specific-character changes that I applied manually, but in the future the AI could be told to do (i.e., not generate unwanted characters). I’m discussing these in the context of AI-generated Briefings, but they are more widely applicable, including to the [English] section. * Replace long dash “–“ (U+2013) with short dash. * Replace single-character ellipsis … with 3 individual dots. * Replace double quotes with single quotes. * Replace directional single quotes (namely ‘ and ’, including latter as apostrophe) with non-directional. Regarding double quotes, replacing them with single quotes is generally best. However, you can in some cases retain a non-directional double quote, but you’d have to escape it (with preceding \ ), and I vaguely recall that doesn’t work under all use cases. Russian has directional double-angle marks as quotes, which you can use. TDM’s ”english” (European) character map repurposes the Latin-1 double-angle codepoints for other purposes. Be aware that the default briefing font renders a straight single quote as if directional. Turning to shortcomings of the default Briefing font (scaled from Carleton 24pt), certain glyphs were never implemented and appear as squares (or artifacts) on-screen. At codepoints 9c-9e (Polish lower-case n with accent, Romanian lower-case s & t with descenders). Likely upper-case 8c-8e are also problematic. Possibilities of what to do: The long-term system-level solution is to complete the font’s character coverage. Awaiting that, you could just leave the FM with the squares/artifacts. In the FM strings, replace these characters with their unaccented base letters. As an interim system-level fix, update the font’s DAT, to replace these characters with their unaccented base letters. For Air Pocket, I’ll do either (1 - awaiting) or (2) at this time. Finally, for Spanish, the TDM standard english/european character map does not support the inverted exclamation mark: ¡. Three FM workarounds: Drop the leading ¡ but retain the trailing !. Make the sentence non-exclamatory, replacing also the trailing ! with a period. (This is what I generally chose.) Likewise drop both marks, but also capitalize the phrase to indicate shouting.

For the re-distribution of briefing text, I thought about basing it on char count, but instead took an easier approach: Move to 2 sentences from the end of page 1 to the start of page 2, then 2 sentences from the end of page 2 to the (empty) page 3. The original page 1 was jam-packed, while the original page 2 was not, so I was less concerned with the latter. This will still need to be verified next time I generate the *.lang files, to make sure there is no truncation at any page bottom. (I had to do the re-distribution for each language, but if I'd done a slimming redistribution of the English early-on, that might have been enough to carry through to other languages. Or possible the AI could manage the redistribution, if you give it a character or word count target. Conjecturally a target around 550 characters per page might work well with the current briefing GUI. I'd ask it not to split sentences.). That leaves the Objectives and Messages to do next.

Well, as usual December was too involved IRL to get anything done in TDM. (Happy New Year, BTW.) On the briefings, I did get a little further since last report. I decided, rather than do tedious patching based on the back-translations, I'd instead change the English source to clarify some phrases, and then re-translate again and call it good enough. This is being expeditious rather than cautious. I expect the briefing translations to on some pages exceed briefing page-text limit. Rather than doing a custom briefing GUI (e.g., with scaling), I instead will edit the .xd to hand-distribute by eyeball the text among the briefing pages.

Amusing, some of translation issues. In the original FM briefing, I referred to "tacky goods". The back-translations from various languages rendered this as "sticky goods". I was intending a different meaning (perhaps a dated Americanism) of "embarrassingly cheap-looking" goods.

After submission, there was some back and forth dialog with ChatGPT about how to structure and batch the output. I let it decide how to denote the language sections (it chose for example "=== German ==="), because I planned to hand-include the results into all.lang (e.g., the "[German]" section). It suggested a few batching options, and I chose 4 languages at a time. (In future, probably 1 at a time would be better to ensure complete batch delivery without pause.) It took maybe 40 minutes to get all the results. While I asked it to update me on progress every few minutes, it only actually reported an update if I poked it. And it seemed to get confused about what was contained in each batch as it delivered it (but actual contents at quick glance were as expected). So when I get time next, I'll archive these results into all.lang, and begin the (time consuming) back-translation verification, looking for flubs and spot fixups. At the end, changes in the lengths of sentences are expected to require manual tweaks (e.g., changing page distributions) for correct display. Pop-up messages in particular may need further customization TBD.

For the FM's text not yet translated, I gave ChatGPT a complex job (in a fresh session, not logged in). The prompt begins... You are an expert translator between English and other European languages, including Russian. You wish to translate a video game, set aboard a small historic merchant sailing ship, from English into these target languages: 1. German 2. French 3. Polish 4. Italian 5. Spanish (as spoken in Spain) 6. Portuguese (as spoken in Portugal) 7. Russian 8. Czech 9. Hungarian 10. Dutch 11. Slovak 12. Danish 13. Swedish 14. Romanian 15. Turkish 16. Catalan. As input, there are 3 lists of English text strings to translate. The 3 lists are respectively in these sections below: A. Objectives B. Thought Messages C. Mission Briefing Each section will start with "Translation Notes:" with additional indented guidance points for that section, then the list itself. Each line of a list begins with a tab, then a word beginning with #str_ within double quotes, then another tab, then a phrase within double quotes. When you translate a line, in the output keep the tabs and the #str_ word unchanged, and only change the phrase to the other target language in UTF-8, keeping it in double quotes. Do not generate Unicode combining characters. Make the translated phrase reasonably short while preserving the formal meaning. Avoid modern slang. Old-fashioned wording is fine. Generate output lists grouped by target language, then within that by section. Also, as separate lines, add comments about any directive that was unclear, or any part of a translation where confidence is low. For consistency with other pre-existing text, it is important to use certain preferred translations, contained in a Glossary below. The Glossary takes the form of a series of 2-column tab-separated tables, one table for each term. In each row, the first column has the language, and the second the corresponding term within quotes. English terms should be matched against the English source text, to drive the translations into other languages. The glossary shows the nominative or noun/subject case, without gender, and when generating translation will be need appropriate declination adjustment to each target language as specific context dictates. Throughout, when translating both "captain" by itself, and "Captain" as a title (e.g., for Riggs), always replace the English term with the translated term from the Glossary. For people names "Riggs" and "Emily", don't translate, except for Russian, transliterate into Cyrillic alphabet. Then the Glossary Tables (detailed in the preceding forum post) appear. After that, the prompt continues with the 3 sections. I'm showing just a sample of A and B here, avoiding spoilers. "Translation Notes" are my guesses, e.g., about needed context for potentially ambiguous phrases... A. Objectives ============= Translation Notes: Objectives are goals the player strives for at various times during game play. "(Opt.)" means "(Optional)"; the translation may use an abbreviation if there is a well-known one. "Capt." means "Captain"; the translation may use an abbreviation if there is a well-known one. "For "sea trunk", use the Glossary. ... "#str_fm_map_obj01_no_hurt_or_loot_crew" "Rile neither the captain nor crew. No assaults by me or gratuitous thieving... not that there's much to steal." "#str_fm_map_obj02_stow_provisions_in_bow_clear_stairs" "Finish stowing the new provisions forward in the bow. Clear them away from the hatch stairs and doorway." ... "#str_fm_map_obj06_opt_get_sword_from_sea_chest" "(Opt.) Retrieve my sword that I put in the sea trunk. I'll likely need it against those who attacked us." ... B. Thought Messages =================== Translation Notes: "keys" are keys to locks on doors or trunks. "My bow's too slippery to handle" is talking about bow and arrows, not ship's bow. "slippery" is due to water. ... ... "#str_fm_map_thought_msg2_keys_missing" "My keys are missing! Must have fallen from my pocket in the attack." ... "#str_fm_map_thought_msg4_bow_unusable" "My bow's too slippery to handle... useless for now! Maybe tomorrow." ... C. Mission Briefing =================== Translation Notes: a "tradeship" is a small merchant vessel with tradegoods. "my sea trunk" is really a ship's sea trunk assigned to the player. Use the Glossary for "sea trunk". "bow galley" refers the galley, which in this ship is located in the ship's bow. Use the Glossary for "galley". "I'm still sore from hauling the goods." Here, "sore" means physically sore, not angry. "sail a half bell" refers to ship's time measured in bells. "His face looked a bit clouded." is a poetic way of saying "He looked worried." "galley hold" is a general storage area within the galley (and not a pantry specifically for food/kitchen items). "ship waist" is the center of the ship, neither bow nor stern. "clearing the mess" refers to clearing dishes after a meal in the ship's mess. Use the Glossary for "mess". "#str_fm_mission_briefing_xd_pg1_body" "Life is sweet! It's been 3 days since Emily ran away with me, leaving behind her bastard husband. He's miles away now, as our tradeship Esmeralda plies herself down the coast.\n\nWe were in luck that Captain Riggs was short of hands. Seems like he's short of funds, too. We had to bribe him with some jewelry to let us crew, particularly a woman.\n\nHe insisted I stow my sword in my sea trunk. Not much trust either way. I've managed to hide some other stuff from him, now up in the crow's nest. But I need to keep on the good side of him and his raggedy crew.\n\nAnyway, Emily's set up a cozy bunk for us in the bow galley.\n" "#str_fm_mission_briefing_xd_pg2_body" "I saw the captain do a lot of haggling and bartering this afternoon, at a village port. I'm still sore from hauling the goods. Since then, we only managed to sail a half bell, before the wind turned unfavorable. Riggs has us anchored in a place he called Shark Jaw Cove. His face looked a bit clouded.\n\nI'll finish moving the new provisions into the galley hold, whilst the two mates stow and secure the tacky tradegoods in the ship's waist. Emily's clearing the mess, then feeding table scraps to the livestock on deck.\n"

I've developed a Glossary for terms that I want to have consistent throughout a given language's translation: "Captain", "First Mate/Officer", "Second Mate/Officer", "Galley", "Mess", and "Sea Trunk". And corrected the previously-done piecemeal translations by hand. In some cases, extra translation was needed to go from the noun/subject case of the Glossary to get gender and other declinations correct, like the "accusative" case in Slavic languages. I then passed 4 of the Glossary terms (in text form from a private spreadsheet, and skipping the 1st and 2nd mates) as part of a new prompt to ChatGPT, to attempt to do all the remaining FM translation work in one big gulp. Four Glossary Tables:

Back to the on-going translation effort. Here’s some general observations and lessons learned while translating the main readable. Recap This readable, mentioned earlier, has an all.lang entry of: [English] // Readables in airpocket.xd: "#str_fm_airpocket_xd_sheet_appointment_to_service_pg1__title" "Appointment to Service\n" "#str_fm_airpocket_xd_sheet_appointment_to_service_pg1_body" "\n\nHEAR YE ALL, that the Bearer is found Fit to Serve, and appointed to the Rank of Ordinary Seaman, aboard the Merchant Ship Esmerelda, by Authority of the Shipmaster, Captain Riggs.\n\nThe Appointee serves Under the Direction & at the Pleasure of the Captain & Officers. By the Law of the Sea known by all, while Aboard, Violations of Duty will be Judged & Punished by the Captain & Those carrying out his Orders. Thievery, Mutiny, Assault, & Other Gross Breeches of Order will be met by Flogging or Death. At Successful Voyage End, the Appointee on Discharge will get the Agreed Wage recorded in the Ship's Log, less any Deductions.\n" "#str_fm_airpocket_xd_sheet_appointment_to_service_pg2__title" "Further Instructions\n" "#str_fm_airpocket_xd_sheet_appointment_to_service_pg2_body" "\n\n\n\nAs agreed, the 2 new crewmates will bunk in the galley, and share the sea trunk nearest the door in the mess.\n\nCaptain Riggs\n" As stated earlier, this text, stripped of #str_ IDs, tabs, and quotes, was given a long directive context prompt and fed into ChatGPT for forward-translation into all the TDM languages. For verification, individual language results were then back-translated (without additional prompt context) into English using Google Translate. Google Translate was also the preferred choice for spot patch-ups. Results were Good Overall Across languages, most sentences appeared to roundtrip-translate quite fine. Some languages (e.g., Turkish) needed more patch up, perhaps due to less AI training or just a greater sentence-structure differential. I did not stress-out about how well the officious over-capitalization of the original was carried over into the translation. Forward-Translation Problem #1 – Piecemeal Translation and Naming Consistency In order to keep this exploration tractable, at the outset I subdivided the collection of English #str_ into various groups (e.g, inventory items, character names (including shouldered), readable, briefing, etc.), and arranged to translate each group separately into all languages. The downside of this is that the subgroups end up with different names for the same thing. This is not unusual IRL, but not real desirable in a game. So, for instance, a key (inventory item) labeled “Mess” (for the door to the ship’s eating place) often has multiple correct nautical translations in a given language. When the word “mess” in the readable is translated, the AI may choose a different one. So patch-up is needed to make the references match. (Future projects might well benefit from a more holistic use of AI.) This problem also affects ranks and titles of persons, about which more next. Forward-Translation Problem #2 – Nautical Ranks and Titles left in English ChatGPT, when translating “...appointed to the Rank of Ordinary Seaman”, almost always left “Ordinary Seaman” in English. And would only sometimes translate “Captain” into a target language. (For a quick look at some suitable nomenclature, type this - “EU commercial nautical deck department ranks in all EU languages - into Google Search and see what the AI provides.) Furthermore, when “Captain” appeared in the readable as a title, e.g., “Captain Riggs”, ChatGPT liked to leave it unchanged. There are two ways to think about that: ChatGPT thinks “Captain” is a first or nickname. ChatGPT thinks that the rank of Captain (and perhaps the surname) implies this is an Englishman, so the rank should be left as conferred by the governing authority. It would be easiest for me to just leave it as “Captain Riggs” throughout. But I’m not really trying to imply Riggs is English, and would think translated immersion would be better if the title was also translated. (I haven’t yet decided which way to go.) Forward-Translation Problem #3 – Lost Nuance affecting a Proximity Clue The last sentence of the readable refers to “the 2 new crewmates ... share the sea trunk nearest the door in the mess.” The English implies that this trunk is *within* the mess. In retrospect, it would have been better to phrase it that way (perhaps I will in the end product’s [English]). Translations into some languages kept this implication; others just said something like the trunk was “near the mess door”, so could be outside the mess. This is a bigger problem than you might think, since the areas involved are underwater and chaotic, so search is difficult. I will do patch-up retranslation where needed.

By themselves, yes. Not with a caption, e.g., a bale of hay with the caption "hay". Within an overall area captioned "Smells" I agree feelings, touch, probably tastes are better off text-only.