Thread:Talk:Issues and features/More information needed or uncertain issues

« P2 FEATURE: add "\n" to the problematic checks for FreeCol. In MediaWiki a newline does not mean anything, in FreeCol it does and is exported as "\n". Number of "\n" in source should be equal to that in destination. »
 * Sorry for reposting this here, but it was reverted, despite the page design looked like a discussion itself given its presentation and the title of the section, which is a call for discussion, starting from a personnal creation !
 * You wrote:
 * « In MediaWiki a newline does not mean anything » : of course this is wrong !!!
 * And this is even the case in plain HTML, with preformated texts that change the interpretation of whitespace, but even elsewhere this can be controled in Javascript (see CSS property 'white-space: pre|nowrap|wrapped'), and in XML (including XHTML) there is also the pseudo-attribute "xml:whitespace=" to change the default (where all whitespaces are considered equal, converted to regular SPACE, then compressed and trimmed).
 * MediaWiki makes even more use of newlines than HTML or XML, as it uses it as part of its syntax for recognizing special characters at the beginning of lines: for numbered/bulletted lists (with "#" and "*"), tables (with "{|" and "|}", table captions (with "|+"), table rows (with "|-"), table data/header cells (with "|" or "!"), definition lists (with ";" and ":"), and blockquotes (with ":" too ; blockquotes are recognized with the same special character if there's no prior line starting with ";" for a defined term and this line contains no ":")
 * MediaWiki also uses the exact number of newlines to make distinctions between a continuation of a text span on the next source line, and a true line break creating a new paragraph (if there are n+1 newlines, MediaWiki creates exactly n new paragraphs if the next character is not one of the special ones, and n-1 paragraphs if these newlines are followed by a special character).
 * The way the newlines are counted are slightly mofified within parameters of Parser Functions and template invokations (because trimming is used on the source text delimited by braces and pipes), or within the text returned by a transcluded template (where only the last newline in its source is dropped), but they are still not completely ignored as well.
 * And outside of table cells and captions a space leading on a line will be used to recognize a preformated line
 * MediaWiki however will trim the contents of all the rest, after it has resolved the special meanings above. Only at this level of parsing, newlines take no more roles.
 * I'm sure that instead you really meant HTML and not MediaWiki (but note that even HTML, XHTML and XML include specific interpretations of newlines, distinct from other whitespaces).

Anyway if you problem is related to the apparent impossibility of Mediawiki of preserving all the newlines present in a resource, the simplest way to solve the problem is to use «  » at start and at end of the resource being edited when there are wanted leading newlines or trailing newlines. Because MediaWiki preserves all the other internal newlines, and only trims the leading and trailing newlines (the empty 'nowiki' element prevents Mediawiki to do that, but generates nothing by itself). And this could solve the problem you have with some Freecol resources (or any other projects in their .po/.pot files for GetText) that use leading or trailing '\n' in their messages.

Note that this conversion from .po/.pot format to Wiki of resources, can perfectly be bijective, even if this requires escaping some newlines using an empty 'nowiki' element. And this is even true if the .po/.pot file contains the string  at start and/or end of a message to translate, that you can also escape by adding another leading and/or trailing one, within MediaWiki. This case, even if it looks very tricky to resove, however should most probably be exceptional or inexistant in practice.