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

Localization support

Aperta
#6 9 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
java
Ambito
cli, internationalization

Direzione di ricerca

Inizia esaminando il branch i18n esistente e gli entry point ParametricBuilder e CommandGraph menzionati nell’issue, quindi traccia i messaggi di runtime hard-coded e le descrizioni e l’help delle annotazioni dei comandi. Confronta l’approccio Java ResourceBundle proposto con il comportamento attuale e con la discussione nei nove commenti. Il lavoro è completato quando esiste un design di localizzazione flessibile e concordato che copra i messaggi interni e il testo dei comandi esterni.

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

Descrizione

Intake should provide some sort of support for localizations. This affects two fields:

  1. Internal localization: All hard-coded strings should be externalized in a Java ResourceBundle and some behaviour might need to be updated in order to work as expected in an localized environment. Some points might need discussion:
    • Intake has several internal runtime exceptions that the end-user should never see (e.g. ParametricException). These might not need localization.
    • It might be a good idea to allow users to alter or replace the internal localization logic by providing custom translations. In that case the two entry points are ParametricBuilder and CommandGraph.
  2. External localization: The values in command annotations, specifically description and help, need localization support. The entry point here is the ParametricBuilder.
    • If localizations use key -> value relationships, as enforced by Java resource bundles, description and help methods would need to return the key. This contradicts the current behaviour where both methods return the actual value, so a support for that old, non localised behaviour is needed.

On both fields, the support should be as flexible as possible and do not enforce any specific way of handling Locales on the user.

Since I need localization support in MyWarp, I have implemented a limited localization support in my own Intake fork (i18n branch). I would be happy to contribute these changes in a PR so there is something to discuss about, if the general direction fits.

Lingua principale
Java
Stelle
102
Fork
18
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

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 EngineHub/Intake

Tutte le issue di EngineHub/Intake

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.