Absolutely, likewise, we need to watch out we don't end up creating a Rube Goldberg machine as a dependency, just to make the translators be able to work with one giant file instead of 4 or 5.
Theres three reasons there is not just one file 1.) So that i18n can be locally customized without needing to merge back the differences every-time you upgrade. 2.) We have different technologies for each webapp, email, controlled vocabularies/taxonomies, etc. 3.) Addon i18n (especially XMLUI Addons) are maintained separately for addon so that you do not need to merge files to upgrade. We have the following areas resources that conain some for of i18n. a. one file for api / jspui (ResourceBundle) b. one or more files for xmlui and addons (Cocoon Messages) d. individual separate files for emails (Custom DSpace wackiness) e. individual taxonomies and controlled vocabs (Custom DSpace wackiness) We need to address requirements for a common design guideline: 1.) A common i18n format would be beneficial 2.) Easily Overriding keys in that format via the Database would be beneficial 3.) Relying on a more common/ubiquitous technology would be beneficial Because of the following, my recommendation for a technical projects roadmap is (and these can be in stages), but a common design and agreement is essential from the beginning. So a/b/c are critical. a.) Implement a Standard JAVA ResourceBundle based i18nTransformer in Cocoon rather than the current format. b.) Decide if we want to use Properties or XML based resource bundles (or allow both) since Java 1.6 or greater is now required. c.) Write JDBC ResourceBundle implementation that can be chained such that above RB are used as defaults and key/values can be overridden. d.) Re-implement Email and taxonomies in the future to use a more ubiquitous templating language that provides support for using ResourceBundles e.) Write user interfaces in xmlui to support overriding i18n keys/values in database. I would look closely at how other projects that leverage Spring WebMVC (and/or other frameworks) approach i18n. I expect in most cases, they all use ResourceBundles. Finally, I will add that the current i18n projects, do not really provide benefit given our yearly release cycle. It would be better to consolidate these back into the DSpace/DSpace master and having i18n maintained in one of these services with additional Release Manager responsibilities for updating files during maintenance releases. I know this is contrary to my past position, my current goal in doing so is to reflect that though we want to addons, it would be better assuring addons carried their own i18n resources instead of multiplying the number of projects necessary to manage an addon and conversely the complexity of DSpace itself. Mark On Tue, Apr 3, 2012 at 1:51 AM, helix84 <[email protected]> wrote: > 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 >> >> > -- [image: @mire Inc.] *Mark Diggory *(Schedule a Meeting<https://www.google.com/calendar/selfsched?sstoken=UUdDSzJzTTlOUE1mfGRlZmF1bHR8MzgwMmEwYjk1NDc1NDQ1MGI0NWViYjYzZjExZDI3Mzg> ) *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010* *Esperantolaan 4, Heverlee 3001, Belgium* http://www.atmire.com
------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
