Domanda

Lavoro sulla localizzazione del software Java e i miei progetti hanno sia file .properties che risorse XML. Attualmente utilizziamo i commenti per indicare ai traduttori di non tradurre determinate stringhe, ma il problema con i commenti è che non sono leggibili automaticamente.

L'unica soluzione che mi viene in mente è quella di aggiungere un prefisso a ogni chiave di non tradurre con qualcosa come _DNT_ e addestrare i nostri strumenti di traduzione per ignorare queste voci. Qualcuno là fuori ha un'idea migliore?

È stato utile?

Soluzione

Potresti suddividere i file in uno da tradurre o in uno da non tradurre e poi inviare loro solo quello da tradurre? (Non conosco la struttura così difficile da sapere quando si risponde se è pratico ...)

Altri suggerimenti

Eclipse JDT utilizza anche commenti per impedire la traduzione di determinate stringhe:

Come scrivere plug-in Eclipse per il mercato internazionale

Penso che il tuo strumento di traduzione dovrebbe funzionare in modo simile?

La soluzione più semplice è quella di non inserire stringhe da non tradurre (DNT) nei file delle risorse.

I file

.properties non offrono molto in termini di gestione dei metadati e poiché non sono necessari i dati in fase di esecuzione, la loro presenza nei file .properties sarebbe un effetto collaterale piuttosto che qualcosa di desiderabile. Considera anche DNT parziali in cui hai qualcosa che non può essere tradotto contenuto in una stringa traducibile (ad esempio un nome commerciale o un URI).

"IDENTIFIER english en en en" -> "french fr IDENTIFIER fr fr"

Per quanto ne so, anche standard come XLIFF non prendere in considerazione i DNT e dovrai gestirli tramite file di metadati personalizzati, file terminologici e / o commenti (come note elemento in XLIFF).

Come axelclk pubblicato nel suo link ... eclipse fornisce un

// $ NON-NLS-1 $

Dichiarazione per notificare al progetto che la prima stringa in questa riga non deve essere tradotta. Tutte le altre stringhe che puoi trovare chiamando Source- > Esternalizza stringhe

Le stringhe esterne includono tutte le lingue che desideri supportare.

File che include le traduzioni simili a: PluginPage.Error1 = text1 PluginPage.Error2 = text2

Classe che legge la traduzione

private static final String BUNDLE_NAME = "com.plugin.name"; //$NON-NLS-1$

    private static final ResourceBundle RESOURCE_BUNDLE = ResourceBundle.getBundle(BUNDLE_NAME);

    private PluginMessages() {
    }

    public static String getString(String key) { 
        // TODO Auto-generated method stub
        try {
            return RESOURCE_BUNDLE.getString(key);
        } catch (MissingResourceException e) {
            return '!' + key + '!';
        }
    }

E puoi chiamarlo come:

String msg = PluginMessages.getString("PluginPage.Error2"); //$NON-NLS-1$

Modifica

Quando una stringa viene esternalizzata e si desidera utilizzare la stringa originale, è possibile eliminare la stringa di esternalizzazione da tutti i file delle proprietà, senza quella predefinita. Quando il pacchetto non riesce a trovare un file di messaggi corrispondente alla lingua locale, viene utilizzato il valore predefinito.

Ma questo non funziona in fase di esecuzione.

Se decidi di utilizzare i commenti da non tradurre nei file delle proprietà, ti consiglio di seguire Convenzione Eclipse . Non è niente di speciale, ma la vita sarà più semplice se tutti usiamo la stessa corda magica!

(Eclipse in realtà non supporta ancora i commenti DO-NOT-TRANSLATE, per quanto ne so, ma Tennera Ant -Gettext ha un'implementazione del suddetto schema che viene utilizzato durante la conversione da pacchetti di risorse in file PO Gettext.)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top