I think Mark makes a number of good points here - esp. regarding modularity -
and it's worth emphasizing that the net effect should be *less* localization
effort, even if there are potentially more files, since one would only need to
worry about the locally deployed modules - but I'm a bit puzzled about the
'single catalog scheme' as a desired future state.
Without much thought, I can come up with 4-5 quite distinct sites (places,
files, ways) where localization occurs in DSpace:
* in email templates (config/email)
* in dspace,cfg and many other config files (starting with the 'dspace.name'
property)
* in input_forms.xml
* messages.xml and that ilk
and I'm sure there are others; the curation stuff does not introduce a new
locus of localization: localizability permeates the application already.
It's also worth noting that localized strings occur not just in the UI proper -
they can appear in RSS feeds, OAI-PMH harvests, etc
So I'd be leery of a plan to shoehorn all localization into any single 'catalog
scheme' , esp. one that is explicitly tied to a UI presentation layer.
Having said all this, I sympathize with Christian's plight, and affirm with
Mark that we can do a better job of managing it.
Richard R.
On Apr 2, 2012, at 9:21 AM, Mark H. Wood wrote:
> On Sat, Mar 31, 2012 at 02:05:34PM +0200, Christian Völker wrote:
> [snip]
>> Now I just found a new flavour of localization in the
>> dspace/config/modules/curate.cfg file:
>>
>> #ui.tasknames = \
>> # profileformats = Profile Bitstream Formats, \
>> # requiredmetadata = Check for Required Metadata, \
>> # checklinks = Check Links in Metadata
>> ui.tasknames = \
>> profileformats = Dateityp angehängter Dateien untersuchen, \
>> requiredmetadata = Pflichtfelder auf Inhalt überprüfen, \
>> checklinks = Links in Metadaten überprüfen
>>
>> # general = General Purpose Tasks,
>> general = Allgemeine Aufgaben,
>>
>> #ui.statusmessages = \
>> # -3 = Unknown Task, \
>> # -2 = No Status Set, \
>> # -1 = Error, \
>> # 0 = Success, \
>> # 1 = Fail, \
>> # 2 = Skip, \
>> # other = Invalid Status
>> ui.statusmessages = \
>> -3 = Unbekannte Aufgabe, \
>> -2 = Kein Zustand definiert, \
>> -1 = Fehlerhaft, \
>> 0 = Erfolgreich, \
>> 1 = Fehlgeschlagen, \
>> 2 = Übersprungen, \
>> other = Ungültiger Zustand
>>
>> Honestly, is this the way to go?
>
> Clearly not. We already have two different message catalog schemes,
> which IMHO is one too many. Configurable message texts should at
> least be confined to those two. It would be good to get every
> component to use a single scheme.
>
>> Bedides the monsterous messages.xml file in
>> modules/xmlui/src/main/webapp/i18n/
>> with more than 2.100 meanwhile, we already have numerous other places now,
>> where to keep messages.xml files updated, in places such as
>>
>> dspace-xmlui/dspace-xmlui-api/src/main/resources/aspects/XMLWorkflow/i18n or
>> dspace-discovery/dspace-discovery-xmlui-api/src/main/resources/aspects/Discovery/i18n
>
> Message catalogs will proliferate, because DSpace is becoming modular.
> Each module needs its own catalog, because it might be released on a
> different schedule, and because separable components shouldn't depend
> on each others' catalogs. Indeed it might be good to break up the
> modules/xmlui/src/main/webapp/i18n/messages.xml into more manageable
> chunks kept closer to the code that uses them, if there is a good and
> sensible way to do it.
>
> We do need to be careful to maintain consistency across modules, and
> to document as well as we can where to find localizable texts.
>
> [snip]
>> I am sorely missing tool support I know of in other programming environments
>> such as AppleGlot or QTLinguist. QTLinguist supports loading several files to
>> compare and copy from and to each other, enabling something like a visual
>> diff.
>> Then, you can create your own dictionaries and load them. You get suggestions
>> based on translations already finished which helps keeping consitency. The
>> file structure cannot be damaged accidentally. Comments with alternative
>> translations or reminders can be added for each message string. And you get
>> an overview of the progress made by checkmarks in the sidebar for
>> translations
>> entered and translations reviewed.
>> The only thing worse in this tool as compared to our files that it is a bit
>> more complicated to find the place where the translation appears on the
>> finished
>> site, depending on the way programmers structured their work.
>
> I agree that good tooling would help. Localization requires a lot of
> comparison and systematic record-keeping, which are hard for humans
> but easy for machines.
>
> There is a proposal right now over on dspace-devel to use web-based
> localization tooling and services. I would invite anyone interested
> in localization to look it over and discuss. See the thread starting
> at Message-ID:
> <CAGO4j2mtQ8Zp4fXA2WYJLinEi_aJDP17UU_hgDUMnw6=rqg...@mail.gmail.com>,
> 24-Mar-2012, Chandan Kumar, "Introduction".
>
>
>> I would really like to see a system which stores all strings inside the
>> database
>> including all translations and adapted translations which override original
>> trans-
>> lations. If one could start translating through the admin interface, this
>> would
>> be a tremendous advantage over the current situation.
>
> I think this falls under the heading of "having a tool is better than
> not." Before we spend a lot of effort to build our own localization
> tools, I think we should look closely at what is already available,
> hoping to let DSpace concentrate on what it is already good at.
> ('emacs' already exists; we don't need to create another one.)
>
> Storing the catalogs in the database brings its own set of problems:
>
> o Existing texts must be loaded into the database. So, we still need
> an external form, at least for loading and exporting texts.
>
> o Currently, when code changes cause significant reorganization of
> the message texts, a new release can simply replace the old
> catalogs with new ones. If we stick the texts into the database
> then we will need to find and clean out obsolete material, or
> provide code to clear the tables and reload.
>
> o We'll need to write a new catalog provider for
> java.util.ResourceBundle and a replacement for
> org.apache.cocoon.transformation.I18nTransformer, which look in the
> database for texts. (We would need to do something like this if we
> consolidated into a single cataloging scheme, no matter where the
> texts are stored.)
>
> I don't claim that these are reasons to reject the idea.
>
> I'd like to suggest that we could make localization easier and better
> by being more systematic. How can we get closer and much earlier
> coordination between Java coders and translators (when they are not
> the same people)? Can we agree on common tooling, or can we provide
> catalogs in forms that work well with many individuals' choices of
> tooling? Every separable piece of DSpace should document where it
> keeps its catalogs, and any areas of its message base where the
> meaning of texts is not obvious.
>
> --
> Mark H. Wood, Lead System Programmer [email protected]
> Asking whether markets are efficient is like asking whether people are smart.
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
> DSpace-tech mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
