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
Received on 2010-11-13 16:34:14 CET