Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Bug] Unit symbols are hardcoded in the sources and cannot be localized

Aperta
#3,416 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
38/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java

Direzione di ricerca

Start with the unit constructors in core/src/main/java/info/openrocket/core/unit/UnitGroup.java and the other call sites named in the report, including CaliberUnit, PercentageOfLengthUnit, DegreeUnit, AppearancePanel, UIPreferencesPanel, and MultiLevelPinkNoiseWindModel. Read how UnitGroup lookup, equality, preferences, and .ork serialization use unit strings before proposing localization, then inspect the message files and existing translator initialization. Done means unit labels can be localized without breaking parsing, stored preferences, or file compatibility.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Describe the bug

Unit symbols shown in the UI are hardcoded string literals in the Java sources. None of them are looked up in the translation files, so every locale displays the same English/ASCII symbols and a translator has no key that could change them. The only localized unit text today is the compass-rose letter used for latitude and longitude (CompassRose.lbl.north/south/east/west). Number formatting is localized (Unit builds its DecimalFormatSymbols from Locale.getDefault(FORMAT)), which is why a Russian locale already renders Длина: 0,5 cm — localized number, untranslatable unit.

Most labels are literals passed to unit constructors in the static initializer of core/src/main/java/info/openrocket/core/unit/UnitGroup.java (lines 107-420), for example:

  • length: mm, cm, m, km, in, in/64, ft, yd, mi, nmi
  • area/inertia/densities: mm², in², ft², kg·m², lb·ft², g/cm³, oz/in³, lb/ft³, g/m², oz/ft², g/cm, oz/ft
  • energy/power/moment: J, erg, BTU, cal, ft·lbf, W, hp, N·m, lbf·in, kg·m/s, N·m·s
  • mass/force: g, kg, oz, lb, N, lbf, kgf, Ns, lbf·s
  • velocity/windspeed: m/s, km/h, ft/s, mph, kt
  • time: ms, s, min, Hz, rpm, r/s, rad/s, °/s
  • temperature/pressure/shear modulus/roughness: K, °C, °F, mbar, bar, atm, mmHg, inHg, psi, Pa, GPa, ksi, µm, mil
  • angle/stability/relative: °, rad, arcmin, cal, %, ‰

A few units are built outside UnitGroup and carry their label in the constructor as well: CaliberUnit ("cal"), PercentageOfLengthUnit ("%"), DegreeUnit (°), AppearancePanel.TEXTURE_UNIT, the scale unit in UIPreferencesPanel, and DegreeUnit in MultiLevelPinkNoiseWindModel. FixedUnitGroup reproduces an arbitrary user-supplied string from a custom expression.

No unit keys exist in any language file. Searching for keys that would name a unit (^unit[._], ^Unit[._]) gives zero hits in messages.properties, messages_de.properties, messages_zh.properties and messages_ru.properties, and the keys that do contain the word unit are dialog labels (pref.dlg.tab.Units, simplotpanel.lbl.Unit, …). This is therefore not an incomplete translation that a locale file could fix.

AI assistance

Model(s): DeepSeek 4.1 Flash (via OpenCode)

AI located the hardcoded labels and their call sites and drafted this report. Every file path, line reference and behaviour described here was checked against the repository.

To Reproduce
  1. Start OpenRocket with a non-English locale, e.g. LANG=ru_RU.UTF-8 (or pick the language in the preferences and restart).
  2. Add or open any component and look at the fields that carry a unit in their label, for example a mass component: the values read Длина: 0,5 cm, Внешний диаметр: 4,6 cm, Внутренний диаметр: 4,6 cm, Толщина стенки: 0 cm, Материал компонента: Картон (0,68 g/cm³), Масса компонента: 0 g.
  3. Compare the number and the unit in the same string: the number is localized (0,5 with a decimal comma), the unit is not (cm, g/cm³, g).
  4. Open the unit chooser next to such a field: every entry is one of the hardcoded labels — cm, mm, m, in, in/64, ft — regardless of language.
  5. Open the preferences, Units tab: the combos that pick the default unit for each quantity show the same untranslated labels.
  6. Switch to a second non-English language (for example German) and repeat: the labels are byte-for-byte identical, so this is not a missing Russian translation.
  7. Optional cross-check without the GUI: searching the message files for keys that would name a unit (^unit[._], ^Unit[._]) returns nothing in any language, so there is no key a translator could fill in.
Screenshots / .ork file

No response

OpenRocket version

unstable

What platform are you running on?

Linux

Additional context
Why the label cannot simply be wrapped in trans.get()

The literal doubles as the unit's identity, so changing the display text affects equality, parsing, preferences and file format:

  • UnitGroup.getUnit(String) and setDefaultUnit(String) resolve a unit by comparing getUnit()
  • Unit.equals/hashCode and UnitGroup.equals compare the string
  • UnitGroup.SIUNITS is keyed by strings such as "m/s" and "kg m^2"
  • ApplicationPreferences.setMultiLevelWindCsvImportAltitudeUnit(Unit) stores unit.toString() as a preference and reads it back with UnitGroup.UNITS_DISTANCE.getUnit(unitString), so a localized toString() would invalidate stored preferences
  • OpenRocketSaver writes the same string into .ork files
  • UnitGroup.fromString(...) accepts a unit typed after the value ("3 cm") and matches it against getUnit(), so users can type the translated label
  • Unit objects are created once in a static initializer, and UnitGroup captures the translator at class-init time (private static final Translator trans = Application.getTranslator();) and uses it for the latitude/longitude labels, so translating in the constructor would freeze the language at that point
Lingua principale
Java
Stelle
3.1k
Fork
703
Merge medio
21h 26m
PR unite (30g)
23

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openrocket/openrocket

Tutte le issue di openrocket/openrocket

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.