Hello,
you probably already know, struggling with localization is one of my favourite
tasks
when dealing with DSpace.
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?
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
These two places seem not to have a corresponding overlay directory.
At least, I was not able to identify them.
Already translated files have to be digged for in awkward places such as
http://scm.dspace.org/svn/repo/modules/dspace-xmlui-lang/trunk/src/main/webapp/i18n/
(success) or
http://scm.dspace.org/svn/repo/dspace/trunk/dspace-discovery/dspace-discovery-xmlui-api/src/main/resources/aspects/Discovery/i18n/
(fail)
Currently I manage over a dozen translation files during a simple version
update.
There are differences in the number of lines for the adapted messages file due
to different settings for e.g. search options to start with. Besides we have a
slightly different lingo as compared to the official translation in our
community
which I have to admit is our own problem. Still, internationalization has taken
place to enable just things like that.
So even if I have decided to switch over to XMLUI and keep updated only this
User Interface and not Messages.properties besides messages.xml and if I further
limit myself and not use the cute new Discovery Feature I am already stuck with
four files per version to keep an eye on and keep in sync:
original english file, original localized file, adapted localized file and
adapted english file which gets merged back the changes applied to the
adapted localized file to support at least the base language as one alternative.
There is never one single point in time when I dont find a glitch with all these
versions despite of extraordinary scrutinity everybody apllies who handles these
files at ours. I even always find minor issues in the versions provided by such
an experienced contributor like Claudia. Besides Id like to take this
opportunity
to say thanks for your continued effort.
Having said that, adding a mere thirty lines or so per version in total nearly
costs a day under these circumstances. And now I discover a new mechanism to be
added. Sorry for only contributing to this list when I have a complaint. But
I am sure there is reason to complain in this case.
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 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.
Bye, Christian
------------------------------------------------------------------------------
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
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
