Re: Extended localization - multiple applications

Hi,

we use a similar approach for some of our applications, where we store 
the translations in the database and give users with translation 
privileges the possibility to translate the textes directly in the 
application. This works quite well and has the advantage that our 
translators can immediately see their translations in the running 
applications, without having to wait for any kind of deployment of the 
texts.

But we also had other applications that were already running and were 
using the Localizable.strings file for translations. Then our customers 
asked for a possibility to translate some texts by themselves. We 
didn't want to change so much in the application, so we sticked with 
the Localizable.strings.

We first tried to send the whole Localizable.strings file to the 
translators, but it was too difficult for them to work directly in 
these files and text encoding was often broken when we got them back. 
So we set up a small web-based application where our translators get a 
list of all the translation keys for an application, and can then enter 
their translations for a certain language. This translations are first 
saved to a database, and from there they can be exported to a 
Localizable.strings file.

We also included a small switch in the translated applications that 
gives a user the possibility to display the translation keys for each 
text, directly in the pages. But this was the only change to the 
applications themselves.

Now the process is: Our translators can switch on the display of the 
translation keys in the application (only for their session and only on 
the development server, of course), then they can go to the translation 
tool and enter their translations there.  When they tell us that they 
have finished some translations, we can export a new 
Localizable.strings from the translation tool and deploy it to our 
application. It's a little more complicated than the first approach 
(for the translators, not for us), but it works without changing much 
in the applications.


Jan


Am 11.04.2006 um 10:11 schrieb André Koppany:

> Hi James,
>
> we run in the past into the same problem to find a easier way for 
> localizing a application.
> Keeping up the Localizable.strings file up to date is not really a 
> nice job. In our case we had
> over 900 keys and four languages.
>
> We decided to create a Localizer Framework which is own eomodel and 
> database.
> There is a LocalizedKey class holding the key and the for each 
> language a field for the localized text.
> This could be also make more dynamically if you do that in your own 
> eo. But for our needs this was the best solution.
>
> The we wrote some components to add and edit keys in a backoffice 
> manner. Also we implemented a reduced editor
> view, where Localization Service People can directly log in and edit 
> the stuff.
>
> To not reinvent the wheel we extend  the ERXLocalizer class from 
> Project Wonder.
> It was something to do, but now we have the possiblity to localize 
> every application very easy by adding the framework to the project,
> defining some properties (url for database, password for edit) and its 
> working.
>
> Best,
>
> André
>
> Am 10.04.2006 um 21:00 schrieb [email protected]:
>
>
>> Date: Mon, 10 Apr 2006 14:57:11 +0200
>> From: "Brook, James" <[email protected]>
>> Subject: Extended localization - multiple applications
>> To: [email protected]
>> Message-ID:
>>  <1FDCE9F824991441A7CE1CFBB0CED3740534BE1A@nlcbbms02.media.ds.upc.biz>
>> Content-Type: text/plain
>>
>> My organization uses WebObjects as its primary means for developing 
>> and
>> deploying dynamic Web applications. These applications are eventually 
>> likely
>> to be deployed across more than 10 European countries. At the moment, 
>> each
>> application contains a 'Localizable.strings' plist for each language 
>> that it
>> supports.
>>
>> We are already running into problems with this approach. We will have 
>> a
>> requirement to share localized strings across multiple applications. 
>> We will
>> have another requirement for non technical Web producers to be able to
>> change the localizations in their own territory.
>>
>> To meet these requirements I envisage some sort of localization 
>> database and
>> an editorial interface for producers to use. It might also be very 
>> useful to
>> be able to provide the producers with some context as to where the 
>> strings
>> get used, so that they understand the consequences of changes that 
>> they
>> make.
>>
>> I am writing to the list to ask if anyone is willing to share any 
>> experience
>> with tackling this sort of problem and what might be the best 
>> approach to
>> take. I am getting very tired of receiving broken plist files, with 
>> badly
>> encoded two byte characters via e-mail and then having to make new 
>> releases
>> of the applications to deploy them!
>>
>> --
>> James
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> WebObjects-dev mailing list
>> [email protected]
>> http://www.omnigroup.com/mailman/listinfo/webobjects-dev
>>
>>
>> End of WebObjects-dev Digest, Vol 11, Issue 10
>> **********************************************
>
> André Koppany                     Bertholdstr.        21
> mackoy consulting               80809 München
> [email protected]               Tel. +49/(0)89/3402 - 90 66
>
>
>
>
> _______________________________________________
> WebObjects-dev mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/webobjects-dev