Fix-#1521 Output the file path in warning message

[tishion]

This PR only enriches the log message with the file path which caused the warning, but it doesn't provide the approach to allow the user to ignore these kind of warnings. Please refer to the issue #1521

[ericstj]

Change LGTM. /cc @dsplaisted for review.

[wli3]

@tishion thank you! did you edit xlf files by hand? You should run ./build.cmd /p:UpdateXlfOnBuild=true to update them after you edit resx to update by build process

[tishion]

@wli3 Updated it by the msbuild, but i found it will not extract the parameter list, so i updated the translated result by adding the parameter list(keep the needs-review-translation status).

[wli3]

@nguerrera do you know how loc team handles the parameter list?

<source>Resolved file has a bad image, no metadata, or is otherwise inaccessible. {0}</source>
 -        <target state="translated">Die aufgelöste Datei enthält ein fehlerhaftes Image oder keine Metadaten, oder der Zugriff ist aus anderen Gründen nicht möglich. {0}</target>
 +        <source>Resolved file has a bad image, no metadata, or is otherwise inaccessible. {0} {1}</source>
 +        <target state="needs-review-translation">Die aufgelöste Datei enthält ein fehlerhaftes Image oder keine Metadaten, oder der Zugriff ist aus anderen Gründen nicht möglich. {0} {1}</target>
          <note />

will they add the {1} for us?

[ericstj]

Test Ubuntu14.04 Debug

[nguerrera]

@wli3 Yes, they will update the placeholders to match. (One subtlety is that it is only safe to add placeholders, not remove them, because if string.Format call passes fewer args than old translation, it will fail until loc catches up.) This change is OK.