Port: Möglichkeiten der Sprachverwaltung für den Geonext-Port

andif

Member
Hallo

Ich bin gerade dabei meinen geonext-Port [Interactive (dynamic) elementary Geometry Software] für FreeBSD zu updaten, allerdings habe ich jetzt seit Geonext 1.11 folgendes Problem und weiß ich nicht wie ich die vielen verschiedenen Sprachversionen am besten manage, da alle nun in einen zip-file sind und ich sie am liebsten in einen Rort haben möchte und nicht für jede Sprachversion einen separaten Port erstellen möchte.

So startet man die deutsche Version über

${JAVA} -cp ${DATADIR}/geonext.jar geonext/Geonext language=de

Die französische Version:
${JAVA} -cp ${DATADIR}/geonext.jar geonext/Geonext language=fr
Die englische Version:
${JAVA} -cp ${DATADIR}/geonext.jar geonext/Geonext language=en

und für die anderen 7Sprachen wiederum das jeweilige Landeskürzel

Wie könnte man dies nun am besten für den Port lösen?

Meine Ideen wären

1. Vorschlag:
geonext:
---------------
#!/bin/sh
${JAVA} -cp ${DATADIR}/geonext.jar geonext/Geonext $1&
---------------

geonext-de, geonext-fr, geonext-en, geonext-?? für die jeweilige Sprache
------------
#!/bin/sh
geonext language={de,fr,en,..}
--------------

Nachteile: mögl. langes Makefile, wahrscheinlich 9nicht benötigte Skripte

2. Vorschlag:
Übergabe der erwünschten Sprache als Variable bei der Installation
z.B make WITH_LANGUAGE=de install

Nachteile: eigentlich werden die übrigen 9Sprachen auch installiert, und bei dieser
Methode wäre es ziemlich umständlich eine von diesen dann doch aufzurufen

3. Vorschlag:

Für jede Sprache einen eigenen Port (wie z.B. bei german/netscape7/)

Was meint ihr? Welche Methode wäre am elegantesten

Andreas
 
Vorschlag 2 erscheint mir persoenlich trotz des genannten Nachteils voellig 'user-friendly' zu sein. Es selten, dass man im Nachhinein die Sprache der Applikation wechselt.
Aber wie gesagt, nur meine persoenliche Meinung.
 
Beim 'mplayer'-Port wird das inzwischen auch über eine Variable (WITH_LANG) gemacht... würd ich auch zu tendieren.


MfG
 
Bedenken

Danke für die Vorschläge,

allerdings hab ich doch einige Bedenken.

1.
So kenn ich schon Umgebungen in denen die verschieden Sprachen im Nachhinein verändert werden.

2. Die Idee mit WITH_LANG find ich eigentlich nicht schlecht, allerdings wird beim mplayer in diesen Fall die Sprache, mit der
er kompiliert werden soll eingestellt(soweit ich das jetzt überblicke), allerdings wird ja eine multilanguale Version auf dem Rechner installiert.

Andreas
 
Zurück
Oben