>>> What was the rationale behind the "strictly" matching path >>> structures? >> There are several reasons. > > Could you tell me which other reasons there are?
Consistency... standardization... an attempt to instill some sanity and organization in the chaos... the ability to find information from an admin standpoint (eg running wiki maintenance bots)... simplifying the creation of Wiki books (aka Collections).... etc. This can all be managed manually, and within a single book in a single language, it's not so hard to deal with... but when you introduce multiple languages it becomes impossible in a *very* short time. Normally, with any random page in the Wiki, it doesn't matter so much if the translation is linked, if the page name is the same as another etc. When we're dealing with the books though, we have dynamic and changing content. If we allow each translation to go off and use whatever layout, naming scheme etc that they want, then how do we manage that long term? For example... lets assume we have a book in the Wiki called OOoStuff. It's originally authored in English and translated to Italian, German, Polish, Chinese and Vietnamese. An expert comes along and identifies a major error in the English version and makes a change. If the German version does not follow the layout and structure (naming, content location and so on) how do we find and correct the error in the German version? If all languages follow the same naming scheme, then it's a simple matter of saying (on the L10N mailing list for example): There is an error that needs to be corrected in all translations of the OOoStuff book on page Documentation/OOoStuff/Section_4/Page_2 and everyone knows exactly where to go to make the changes. Assume that the person who translated the German document decided to do things differently (for reasons that made sense at the time), and put that same information on (and I'm going to show how bad my German is here :-) ) DE/Documentation/OOoZeug/Blatt_6/Abschnitt_3/Unterabschnitt_7 If you're not the original translator and/or don't know the document intimately, how can you be sure to find that section that needs to be changed? Another (real life) example. Yesterday I had a request to help create an Italian ODT and PDF of the Basic Guide. Because the Italian translation of the Basic Guide followed the same page layout/naming as the English version, I could quickly create the book, and generate and ODT. Now, it could have been done manually, but in about 10x the time. With everything "standardized" and consistent, it was quite easy to pull things together (ie build the Book file content) and produce the required document. > Sorry but, for the User Guides, this is a minor requirement, nice to > have but absolutely unnecessary for 99% of the end users - which often > are software newbies and just want to learn the basics. They don't need > to switch to Chinese by one click ;) What about a German user who arrives on the Wiki and ends up at the English guide? He or she may be able to manage OK in English but would be much much more comfortable reading in German. Providing that quick link to get them to their native language when it's available seems to me to be a rather important aspect here - especially in light of the fact that we have such a mishmash of languages and information in the Wiki. > Are there any *important* obstacles? ;-) I think I've highlighted a few above. :-) We started out with things being a lot more free form and almost immediately it became clear that if we want to have even a remote chance of keeping the docs somewhat in synch between the languages without needing to totally re-translate everything every X months then we absolutely need to implement some structure of some form or another. If you or anyone else reading this thread have any ideas on how we can make changes and still keep things manageable... speak up. We've set out the guidelines and so on based on what looked best for everyone... that can change (and should change as new requirements appear)... but... I don't want to see it change just because someone doesn't quite like it and it doesn't quite fit with his or her view of things. If it changes, it needs to be a change that improves things for all languages involved... something that makes the overall management and "keeping track of it all" easier or better in the long run (eg the work done recently on the MasterTOC is a prime example of making changes to dramatically improve things over what they were). C. -- Clayton Cornell ccorn...@openoffice.org OpenOffice.org Documentation Project co-lead StarOffice - Sun Microsystems, Inc. - Hamburg, Germany --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org For additional commands, e-mail: dev-h...@documentation.openoffice.org
