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.
pgpSQ0uiIrWm1.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
