Pretty please, don't reinvent the wheel poorly, just give us translators
.po files (preferably one). Then there are existing tools like Pootle and a
bazillion others for things like online translation and reusing old
translations.
That's all I have to say, but I can't stress it enough.
Regards,
~~helix84
On Tue, Apr 3, 2012 at 05:53, Mark Diggory <[email protected]> wrote:
> 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.
>
>
> [image: @mire Inc.]
> *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
>
> 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' 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
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
------------------------------------------------------------------------------
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
