Sounds reasonable.

What changes to the source code would be required?

Do we just change
        N_("three\n\nparagraphs\n\nhere\n")
to
        N_("three\n") N_("paragraphs\n") N_("here\n")
?

Dongsheng Song wrote on Sat, Nov 13, 2010 at 23:18:08 +0800:
> Hi folks,
> 
> subversion.pot have some very long translated message, for example:
> 
> Apply a patch to a working copy.\n
> usage: patch PATCHFILE [WCPATH]\n
> \n
>  Apply a unidiff patch in PATCHFILE to the working copy WCPATH.\n
>  If WCPATH is omitted, '.' is assumed.\n
> \n
>  A unidiff patch suitable for application to a working copy can be\n
>  produced with the 'svn diff' command or third-party diffing tools.\n
>  Any non-unidiff content of PATCHFILE is ignored.\n
> \n
>  Changes listed in the patch will either be applied or rejected.\n
>  If a change does not match at its exact line offset, it may be applied\n
>  earlier or later in the file if a match is found elsewhere for the\n
>  surrounding lines of context provided by the patch.\n
>  A change may also be applied with fuzz, which means that one\n
>  or more lines of context are ignored when matching the change.\n
>  If no matching context can be found for a change, the change conflicts\n
>  and will be written to a reject file with the extension .svnpatch.rej.\n
> \n
>  For each patched file a line will be printed with characters reporting\n
>  the action taken. These characters have the following meaning:\n
> \n
>    A  Added\n
>    D  Deleted\n
>    U  Updated\n
>    C  Conflict\n
>    G  Merged (with local uncommitted changes)\n
> \n
>  Changes applied with an offset or fuzz are reported on lines starting\n
>  with the '>' symbol. You should review such changes carefully.\n
> \n
>  If the patch removes all content from a file, that file is scheduled\n
>  for deletion. If the patch creates a new file, that file is scheduled\n
>  for addition. Use 'svn revert' to undo deletions and additions you\n
>  do not agree with.\n
> 
> From the translator's point of view, this very hard for translate and 
> maintain.
> So I proposed we should split these long message like mercurial.
> 
> --
> Dongsheng

Reply via email to