yvz1p
My feedback
31 results found
-
2 votesyvz1p
supported this idea
·
-
1 vote
An error occurred while saving the comment An error occurred while saving the comment yvz1p
commented
Part 2 of 2
11. Number formatting: decimal and thousands separators independently configurable: 1,234.56 (Australia, UK, US, China, Japan, most of Asia); 1.234,56 (Germany, Spain, Brazil, much of Europe and Latin America); thin space 1 234,56 (France, Nordics, SI/ISO standard); Swiss apostrophe 1'234.56; Indian lakh and crore grouping (1,23,456.78); Arabic-Indic numerals; and ten-thousand (myriad) grouping in Chinese and Japanese conventions. The same number in the wrong convention is actively misread, and Indian-format numbers are mangled by systems that only understand three-digit grouping.
12. Paper size conventions: ISO A and B series, US Letter and Legal, JIS B series and traditional Japanese sizes (Shiroku-ban, Kiku), ANSI series, and Latin American formats (Colombian carta and oficio, Philippine long legal), applied when Lumo generates or advises on document layout and printable output.
13. Cultural reference conventions: region-appropriate examples for pricing, quantities, food and institutions rather than US defaults; an Australian asking about coffee prices should get AUD, not USD.
14. Academic citation styles: a selectable referencing format (Harvard, APA, MLA, Chicago, Oxford and others) applied whenever Lumo assists with research, bibliographies and study material.
15. Application to Ghost Mode: each setting should have a toggle controlling whether it also applies in Ghost Mode chats, which disappear on closing. A user's regional reality does not change because a chat is temporary, though the temporal awareness toggle could sensibly default off in Ghost Mode for users wanting the most minimal-data configuration.
Central management: these settings should be tied to the Proton Account and available across all applicable Proton apps (Mail, Calendar, Meet, VPN, Pass, Authenticator, Drive, Docs, Sheets, Wallet, Lumo, Bridge), each offering two modes: applied to all apps, or per app (for example day-first dates everywhere but a different currency display in Proton Wallet than in Lumo). Not every setting applies to every product, so each appears wherever relevant. Users configure their regional reality once instead of separately in each app, which is the fragmentation regional settings exist to eliminate. The temporal awareness toggle aligns with Proton's privacy-first ethos, and the settings would complement persistent memory by replacing custom-instruction workarounds.
Competitor landscape: structured regional settings already exist at operating-system level: Apple's Language and Region settings allow independent configuration of calendar format, temperature unit, measurement system, first day of the week, date format and number format, inherited by Siri and Apple Intelligence. Microsoft offers regional customisation in Windows but not in Copilot, where users report preferences reverting to US conventions. No major AI assistant (ChatGPT, Gemini, Claude, Copilot) offers these settings natively. Proton would be the first AI assistant to ship structured, composable regional settings.
If you read this far, thank you, please vote in support if you would like to see these features added, and thank you to the team at Proton/Lumo.
yvz1p
shared this idea
·
-
1 voteyvz1p
shared this idea
·
-
80 votesyvz1p
supported this idea
·
-
9 votes
An error occurred while saving the comment yvz1p
commented
This x 10000000. It's terrible that Lumo itself isn't even aware of its own latest updates/features/functions, let alone the rest of the Proton suite and what formats its various apps/services are available on and compatible with.
I have numerous prompts in place in an attempt to stop Lumo from defaulting to training data on various topics where up-to-date information pulled from conducting web searches and citing multiple reliable sources is imperative. Yet in spite of this, and despite having persistent memory enabled, Lumo still picks and chooses when to implement it, without disclosing it to me in its response. It does this even when explicitly instructed with manual chat prompts. It's so tedious having to constantly repeat myself in the same chat, let alone all chats.
A simpler fix than retraining would be transparency: for anything concerning Lumo or Proton features, the assistant should either check current documentation before answering or state plainly that it has not, and every response should disclose what was verified versus what came from training data. In my view that behaviour change would resolve most of the problem.
This post needs more visibility. I really hope the Lumo team prioritises this.
yvz1p
supported this idea
·
-
30 votesyvz1p
supported this idea
·
-
11 votesyvz1p
supported this idea
·
-
146 votesyvz1p
supported this idea
·
-
39 votesyvz1p
supported this idea
·
-
10 votesyvz1p
supported this idea
·
-
12 votesyvz1p
supported this idea
·
-
45 votesyvz1p
supported this idea
·
-
8 votesyvz1p
supported this idea
·
-
8 votesyvz1p
supported this idea
·
-
8 votesyvz1p
supported this idea
·
-
44 votesyvz1p
supported this idea
·
-
29 votesyvz1p
supported this idea
·
-
48 votesyvz1p
supported this idea
·
-
108 votesyvz1p
supported this idea
·
-
70 votesyvz1p
supported this idea
·
Part 1 of 2
Lumo has language selection but no regional settings governing how it formats and reasons about measurements, currency, dates and times. For non-US users this creates constant friction, and unlike a static app, an assistant actively generates this content. Critically, these settings should shape how Lumo thinks, not just how it writes: the selected English variant should govern reasoning and drafting, so drafting in British English means composing in British English from the first word, not converting afterwards.
Requested options, ideally as one Region preference with independently configurable sub-settings. The examples below are illustrative, not exhaustive: the request is coverage of formats in use by everyone in every country globally, with custom options catching the remainder.
1. English variants with full grammar and punctuation rules: en-GB, en-AU, en-NZ, en-IE, en-CA, en-IN, en-ZA and en-US, each governing spelling, vocabulary, idioms and punctuation (quotation mark style, serial comma, organisation vs organization, learnt vs learned). A single undifferentiated English option collapses these into a de facto American default.
2. Separately selectable proofreading conventions: the English variant Lumo applies to proofreading and rewriting, set independently of interface language.
3. Temporal awareness toggle: optional current date and time awareness using a user-specified time zone rather than system detection (avoiding location leakage), correct daylight saving rules per zone (regions change on different dates and some never observe it), fractional offsets (UTC+5:30 India, UTC+5:45 Nepal, UTC+12:45 Chatham Islands, UTC+13 and +14 zones), 24h or 12h clock, and explicit offset display for cross-zone times.
4. Measurement units: user-selectable metric or imperial, governing both how quantities are expressed and how input is interpreted, since mixing systems causes errors in cooking, medication dosing and distances.
5. Temperature scale: Celsius or Fahrenheit, configurable independently of general units.
6. Currency: a default display currency (AUD, GBP, EUR, NZD, CAD, INR and so on) so financial discussion does not assume USD, with conversion on request only.
7. Date format independent of language: DD/MM/YYYY, MM/DD/YYYY, ISO YYYY-MM-DD, YYYY/MM/DD, D.M.YYYY, plus alternative calendars (Islamic Hijri, Hebrew, Japanese era, Thai Buddhist, Persian Solar Hijri, Indian Saka, among others). Configuring independently prevents 09/01/2026 being read as two different dates eight months apart by day-first and month-first users.
8. Week start: Monday, Sunday or Saturday (including the Persian and Arabic convention where Saturday is first), with optional ISO week numbering.
9. Holiday awareness for scheduling: terminology varies by region (public, bank, federal and statutory holidays) and dates vary sub-nationally and nationally (Australian states and territories, Indian central and state lists, Canadian provinces, every country's national days). Lunar New Year named per locale: Spring Festival in mainland China and Taiwan, Seollal in Korea, Tet in Vietnam, Losar, Tsagaan Sar, Imlek. Other East and Southeast Asian observances (Chuseok, Mid-Autumn Festival, Qingming). Religious observances across every major tradition, with an option to surface global religious holidays rather than only local ones. School terms and academic years by jurisdiction, respecting different year boundaries (Southern Hemisphere January/February, Japan April, Korea March, Northern Hemisphere September). Moon phase and lunisolar calendar tracking. Users spanning multiple jurisdictions should be able to subscribe to several calendars simultaneously.
10. Financial year conventions: calendar year; 1 July to 30 June (Australia, New Zealand); 1 April to 31 March (India, Japan, UK government); 6 April to 5 April (UK personal tax); 1 October to 30 September (US federal); and a custom start date covering any other system globally (such as Nepal's mid-July year). Without this, budgeting and tax assistance risks silently assuming the calendar year.