merge the DiffLang to left_to_do

.gitignore

@@ -5,4 +5,5 @@ checkout/
 dist/
 output/
 /local.properties
-bin/
+bin/
+tmp/

left_to_do.groovy

@@ -5,15 +5,16 @@
  * user guide translation with another gdoc source directory. By default,
  * the translation is compared against the reference 'en' docs.
  */
-if (!args || args.size() > 2) {
+if (!args || args.size() > 3) {
     println """\
         USAGE
         
-          left_to_do LANG [LANG]
+          left_to_do LANG [LANG] [-nc]
 
         where
 
           LANG = a language code, e.g. 'en' or 'pt_BR'
+          -nc means: copy the new file if the target LANG file does not exist
 
         Compares the contents of the {hidden} blocks in the user guide for the first language
         against the entire contents of the second language. By default, the second language
@@ -40,6 +41,9 @@ if (!srcDir.exists()) {
     println "No source directory for language '${args[0]}'"
     System.exit 2
 }
+def refDir = new File("src", args.size() >= 2 ? args[1] : 'en')
+def isNc = (args.size() >= 3 && args[2]=='-nc') ? true :false
+def ant = new AntBuilder()
 
 srcDir.eachFileRecurse { f ->
     if (f.directory) {
@@ -51,13 +55,20 @@ srcDir.eachFileRecurse { f ->
         // name and relative location, and write out the contents of
         // {hidden} blocks to that target file. Note the target file
         // will include the {hidden} macros.
-        def targetFile = new File(tmpDocDir, relativePath(srcDir, f))
+        def relPathStr = relativePath(srcDir, f)
+        def targetFile = new File(refDir, relPathStr)
+        if (isNc && !targetFile.exists()) {
+            if (!targetFile.parentFile.exists()) {
+                targetFile.parentFile.mkdirs()
+            }
+            ant.copy(file:f,tofile:targetFile)
+        }
+        targetFile = new File(tmpDocDir, relPathStr)
         writeHiddenToFile f.text, targetFile
     }
 }
 
 // Now recursively diff the generated files against the reference directory.
-def refDir = new File("src", args.size() == 2 ? args[1] : 'en')
 generateDiff refDir, tmpDocDir
 
 /// End of script execution ///

src/zh_CN/guide/contributing.gdoc

@@ -0,0 +1 @@
+You can contribute to Grails in a number of different ways.

src/zh_CN/guide/contributing/build.gdoc

@@ -0,0 +1,78 @@
+In order to build Grails from source and run the tests, you need to first have the following pre-requisites.
+* JDK (1.6+)
+* Git client
+
+Once you have all the pre-requisite packages installed, the next step is to download the Grails source code. The source code is hosted at [GitHub|http://github.com] in several different git repositories owned by the ["grails" GitHub user|http://github.com/grails].
+
+To download the source using git, use the "git clone" command followed by the public URL of the repository you want to clone (download). For example, to clone the "grails-core" repository, run the following:
+{code}
+git clone http://github.com/grails/grails-core.git
+{code}
+
+The above will create a "grails-core" directory in your current working directory populated with the project source and the git repository.
+
+h3. Create the required jars
+{code}
+./gradlew libs
+{code}
+
+This will create everything you need to run Grails. This target also skips running the extensive collection of Grails test classes (Grails' 1000+ tests can bring a single core processor to a grinding halt for some time).
+
+Once the jars have been built, simply set GRAILS_HOME to the checkout directory and add the "bin" directory to your path.
+
+h3. Run the test suite
+
+All you have to do to run the full suite of tests is:
+{code}
+./gradlew test
+{code}
+
+These will take a while (15-30 mins), so consider running individual tests using the command line. For example, to run the tests in src/test/org/codehaus/groovy/grails/orm/hibernate/MappingDslTests.groovy, run the following command:
+{code}
+./gradlew -Dtest.single=MappingDslTest grails-test-suite-persistence:test
+{code}
+
+You need to give it the specific test suite that the test exists in, just using the "test" target won't work.
+
+h3. Developing in IntelliJ IDEA
+
+You need to run the following gradle task:
+{code}
+./gradlew idea
+{code}
+
+Then open the project file which is generated in IDEA. Simple!
+
+h3. Developing in STS / Eclipse
+
+You need to run the following gradle task:
+{code}
+./gradlew cleanEclipse eclipse
+{code}
+
+Before importing projects to STS do the following action:
+* Edit grails-scripts/.classpath and remove the line "<classpathentry kind="src" path="../scripts"/>".
+
+Use "Import->General->Existing Projects into Workspace" to import all projects to STS. There will be a few build errors. To fix them do the following actions:
+* Add "~/.gradle/cache/com.springsource.springloaded/springloaded-core/jars/springloaded-core-XXXX.jar" to grails-core's classpath.
+* Remove "src/test/groovy" from grails-plugin-testing's source path GRECLIPSE-1067
+* Add "~/.gradle/cache/javax.servlet.jsp/jsp-api/jars/jsp-api-2.1.jar" to the classpath of grails-web
+* Fix the source path of grails-scripts. Add linked source folder linking to "../scripts". If you get build errors in grails-scripts, do "../gradlew cleanEclipse eclipse" in that directory and edit the .classpath file again (remove the line "<classpathentry kind="src" path="../scripts"/>"). Remove possible empty "scripts" directory under grails-scripts if you are not able to add the linked folder.
+* Do a clean build for the whole workspace.
+* To use Eclipse GIT scm team provider: Select all projects (except "Servers") in the navigation and right click -> Team -> Share project (not "Share projects"). Choose "Git". Then check "Use or create repository in parent folder of project" and click "Finish".
+* Get the recommended code style settings from the [mailing list thread|http://grails.1312388.n4.nabble.com/Grails-development-code-style-IDE-formatting-settings-tp3854216p3854216.html] (final style not decided yet, currently [profile.xml|http://grails.1312388.n4.nabble.com/attachment/3854262/0/profile.xml]). Import the code style xml file to STS in Window->Preferences->Java->Code Style->Formatter->Import . Grails code uses spaces instead of tabs for indenting.
+
+h3. Debug
+
+To debug Grails run the Grails application using:
+{code}
+grails-debug <command>
+{code}
+
+and then connect to it remotely via the IDE. There should be an option for "remote debugging". Unless you modify the "grails-debug" script, you should connect to port 5005.
+
+If you need to debug stuff that happens during application start-up, then you should modify the "grails-debug" script and change the "suspend" option from 'n' to 'y'.
+
+You can read more about the JPDA Connection settings here: [http://java.sun.com/j2se/1.5.0/docs/guide/jpda/conninv.html#Invocation|http://java.sun.com/j2se/1.5.0/docs/guide/jpda/conninv.html#Invocation]
+
+It's also possible to get Eclipse to wait for incoming debugger connections and instead of using "-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005" you could use this "-Xrunjdwp:transport=dt_socket,server=n,address=8000" (which assumes the Eclipse default port for remote java applications) Inside eclipse you create a new "Remote Java Application" launch configuration and change the connection type to "Standard (Socket Listen)" and click debug. This allows you to start a debugger session in eclipse and just leave it running and you're free to debug anything without having to keep remembering to relaunch a "Socket Attach" launch configuration. You might find it handy to have 2 scripts, one called "grails-debug", and another called "grails-debug-attach"

src/zh_CN/guide/contributing/issues.gdoc

@@ -0,0 +1 @@
+Grails uses [JIRA|http://jira.grails.org] to track issues. If you’ve found a bug, this is the place to start. You’ll need to create a (free) JIRA account in order to either submit an issue or comment on them.

src/zh_CN/guide/contributing/patchesCore.gdoc

@@ -0,0 +1,58 @@
+If you want to submit patches to the project, you simply need to fork the repository on GitHub rather than clone it directly. Then you will commit your changes to your fork and send a pull request for a core team member to review.
+
+h3. Forking and Pull Requests
+One of the benefits of [GitHub|http://github.com] is the way that you can easily contribute to a project by [forking the repository|http://help.github.com/fork-a-repo/] and [sending pull requests|http://help.github.com/send-pull-requests/] with your changes.
+
+What follows are some guidelines to help ensure that your pull requests are speedily dealt with and provide the information we need. They will also make your life easier!
+
+h4. Create a local branch for your changes
+
+Your life will be greatly simplified if you create a local branch to make your changes on. For example, as soon as you fork a repository and clone the fork locally, execute
+{code}
+git checkout -b mine
+{code}
+
+This will create a new local branch called "mine" based off the "master" branch. Of course, you can name the branch whatever you like - you don't have to use "mine".
+
+h4. Create JIRAs for non-trivial changes
+
+For any non-trivial changes, raise a JIRA issue if one doesn't already exist. That helps us keep track of what changes go into each new version of Grails.
+
+h4. Include JIRA issue ID in commit messages
+
+This may not seem particularly important, but having a JIRA issue ID in a commit message means that we can find out at a later date why a change was made. Include the ID in any and all commits that relate to that issue. If a commit isn't related to an issue, then there's no need to include an issue ID.
+
+h4. Make sure your fork is up to date
+
+Since the core developers must merge your commits into the main repository, it makes life much easier if your fork on GitHub is up to date before you send a pull request.
+
+Let's say you have the main repository set up as a remote called "upstream" and you want to submit a pull request. Also, all your changes are currently on the local "mine" branch but not on "master". The first step involves pulling any changes from the main repository that have been added since you last fetched and merged:
+{code}
+git checkout master
+git pull upstream
+{code}
+
+This should complete without any problems or conflicts. Next, rebase your local branch against the now up-to-date master:
+{code}
+git checkout mine
+git rebase master
+{code}
+
+What this does is rearrange the commits such that all of your changes come after the most recent one in master. Think adding some cards to the top of a deck rather than shuffling them into the pack.
+
+You'll now be able to do a clean merge from your local branch to master:
+{code}
+git checkout master
+git merge mine
+{code}
+
+Finally, you must push your changes to your remote repository on GitHub, otherwise the core developers won't be able to pick them up:
+{code}
+git push
+{code}
+
+You're now ready to send the pull request from the GitHub user interface.
+
+h4. Say what your pull request is for
+
+A pull request can contain any number of commits and it may be related to any number of issues. In the pull request message, please specify the IDs of all issues that the request relates to. Also give a brief description of the work you have done, such as: "I refactored the data binder and added support for custom number editors (GRAILS-xxxx)".

src/zh_CN/guide/contributing/patchesDoc.gdoc

@@ -0,0 +1,91 @@
+Contributing to the documentation is much simpler from the core framework because there is a replica of the [http://github.com/grails/grails-doc|http://github.com/grails/grails-doc] project that anyone can request commit access on. So, if you want to submit patches to the documentation, you simply need to request commit access to the following repository [http://github.com/pledbrook/grails-doc|http://github.com/pledbrook/grails-doc] and commit your patches just as you would any other GitHub repository.
+
+h3. Building the Guide
+To build the documentation, simply type:
+{code}
+./gradlew docs
+{code}
+
+Be warned: this command can take a while to complete and you should probably increase your Gradle memory settings by giving the @GRADLE_OPTS@ environment variable a value like
+{code}
+export GRADLE_OPTS="-Xmx512m -XX:MaxPermSize=384m"
+{code}
+
+Fortunately, you can reduce the overall build time with a couple of useful options. The first allows you to specify the location of the Grails source to use:
+{code}
+./gradlew -Dgrails.home=/home/user/projects/grails-core docs 
+{code}
+
+The Grails source is required because the guide links to its API documentation and the build needs to ensure it's generated. If you don't specify a @grails.home@ property, then the build will fetch the Grails source - a download of 10s of megabytes. It must then compile the Grails source which can take a while too.
+
+Additionally you can create a local.properties file with this variable set:
+{code}
+grails.home=/home/user/projects/grails-core
+{code}
+or
+{code}
+grails.home=../grails-core
+{code}
+
+The other useful option allows you to disable the generation of the API documentation, since you only need to do it once:
+{code}
+./gradlew -Ddisable.groovydocs=true docs
+{code}
+
+Again, this can save a significant amount of time and memory.
+
+The main English user guide is generated in the @build/docs@ directory, with the @guide@ sub-directory containing the user guide part and the @ref@ folder containing the reference material. To view the user guide, simply open @build/docs/index.html@.
+
+h3. Publishing
+The publishing system for the user guide is the same as [the one for Grails projects|http://grails.org/doc/2.0.0.M1/guide/conf.html#docengine]. You write your chapters and sections in the gdoc wiki format which is then converted to HTML for the final guide. Each chapter is a top-level gdoc file in the @src/<lang>/guide@ directory. Sections and sub-sections then go into directories with the same name as the chapter gdoc but without the suffix.
+
+The structure of the user guide is defined in the @src/<lang>/guide/toc.yml@ file, which is a YAML file. This file also defines the (language-specific) section titles. If you add or remove a gdoc file, you must update the TOC as well!
+
+The @src/<lang>/ref@ directory contains the source for the reference sidebar. Each directory is the name of a category, which also appears in the docs. Hence the directories need different names for the different languages. Inside the directories go the gdoc files, whose names match the names of the methods, commands, properties or whatever that the files describe.
+
+h3. Translations
+This project can host multiple translations of the user guide, with @src/en@ being the main one. To add another one, simply create a new language directory under @src@ and copy into it all the files under @src/en@. The build will take care of the rest.
+
+Once you have a copy of the original guide, you can use the @\{hidden\}@ macro to wrap the English text that you have replaced, rather than remove it. This makes it easier to compare changes to the English guide against your translation. For example:
+{code}
+\{hidden\}
+When you create a Grails application with the [create-app|commandLine] command,
+Grails doesn't automatically create an Ant @build.xml@ file but you can generate
+one with the [integrate-with|commandLine] command:
+\{hidden\}
+
+Quando crias uma aplicação Grails com o comando [create-app|commandLine], Grails
+não cria automaticamente um ficheiro de construção Ant @build.xml@ mas podes gerar
+um com o comando [integrate-with|commandLine]:
+{code}
+
+Because the English text remains in your gdoc files, @diff@ will show differences on the English lines. You can then use the output of @diff@ to see which bits of your translation need updating. On top of that, the @\{hidden\}@ macro ensures that the text inside it is not displayed in the browser, although you can display it by adding this URL as a bookmark: @javascript:toggleHidden();@ (requires you to build the user guide with Grails 2.0 M2 or later).
+
+Even better, you can use the @left_to_do.groovy@ script in the root of the project to see what still needs translating. You run it like so:
+{code}
+./left_to_do.groovy es
+{code}
+
+This will then print out a recursive diff of the given translation against the reference English user guide. Anything in @\{hidden\}@ blocks that hasn't changed since being translated will _not_ appear in the diff output. In other words, all you will see is content that hasn't been translated yet and content that has changed since it was translated. Note that @\{code\}@ blocks are ignored, so you _don't_ need to include them inside @\{hidden\}@ macros.
+
+To provide translations for the headers, such as the user guide title and subtitle, just add language specific entries in the 'resources/doc.properties' file like so:
+{code}
+es.title=El Grails Framework
+es.subtitle=...
+{code}
+
+For each language translation, properties beginning @<lang>@. will override the standard ones. In the above example, the user guide title will be El Grails Framework for the Spanish translation. Also, translators can be credited by adding a '<lang>.translators' property:
+{code}
+fr.translators=Stéphane Maldini
+{code}
+
+This should be a comma-separated list of names (or the native language equivalent) and it will be displayed as a "Translated by" header in the user guide itself.
+
+You can build specific translations very easily using the @publishGuide_\*@ and @publishPdf_\*@ tasks. For example, to build both the French HTML and PDF user guides, simply execute
+{code}
+./gradlew publishPdf_fr
+{code}
+
+Each translation is generated in its own directory, so for example the French guide will end up in @build/docs/fr@. You can then view the translated guide by opening @build/docs/<lang>/index.html@.
+
+All translations are created as part of the [Hudson CI build for the grails-doc|http://hudson.grails.org/job/grails_docs_2.0.x/lastSuccessfulBuild/artifact/build/docs/] project, so you can easily see what the current state is without having to build the docs yourself.