I agree that it shouldn't be exclusively in the UI layer.
I do support the idea of, if not a centralized catalog where all values reside,
then at least the ability to define a catalog that allows Repository Admins to
easily override the existing values found in the files from the UI. In fact,
IMO, it should really be in the database in a manner that, similar to
configuration modularization would be separated up into contexts based on
context.
localization_catalog
{
context
key
value
lang
}
Individual email templates (which are glorified parameterized messages),
messages.xml and messages.properties all residing within one database table
would shift the design of internationalization away from a developer activity.
Simple tooling can be written to to dump/restore the database from properties
files (xml or properties formats) as needed.
Simple interfaces can be crafted in the admin area of the user interface to
introduce simple editing of the field values and
Caching can be employed in the XMLUI to optimize performance and reduce db
queries for i18n tags.
Mark Diggory (Schedule a Meeting (http://bit.ly/xNePTl))
2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010
Esperantolaan 4, Heverlee 3001, Belgium
http://www.atmire.com (http://www.atmire.com/)
On Monday, April 2, 2012 at 11:02 AM, Richard Rodgers wrote:
> 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
> (http://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
> > (mailto:[email protected])>,
> > 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]
> > (mailto:[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] (mailto:[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] (mailto:[email protected])
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
