Comment 4 for bug 513331

Hi Richard,
you've found the reason!
Switching to English has solved the issue but, since we're interested in using mainly Italian, we're currently using the pack found here: http://wiki.mahara.org/Download_Mahara.
The issue is around "è" being not saved as a valid UTF-8 char (no mb if you look at it using an Hex view):

# diff -u blocktype.externalvideo.php.orig blocktype.externalvideo.php
--- blocktype.externalvideo.php.orig 2010-01-29 14:24:15.000000000 +0100
+++ blocktype.externalvideo.php 2010-01-29 14:27:10.000000000 +0100
@@ -29,8 +29,8 @@
 $string['title'] = 'Video esterni';
 $string['description'] = 'Video esterni incorporati';
 $string['videourl'] = 'URL del Video';
-$string['videourldescription2'] = 'Incolla il codice incorporato o l\'URL della pagina dove il Video è localizzato. Puoi aggiungere video incorporati dai seguenti siti:';
+$string['videourldescription2'] = 'Incolla il codice incorporato o l\'URL della pagina dove il Video e\' localizzato. Puoi aggiungere video incorporati dai seguenti siti:';
 $string['width'] = 'Larghezza';
 $string['height'] = 'Altezza';

-?>
\ No newline at end of file
+?>

e.g. using an ASCII representation of the accent ("é" -> "e'") solves the issue.

Questions:
1. Is it possible to avoid such blocking issues for any fault from "L10N" even encoding ones e.g. catching some way the exception? Maybe using a combination of prepending "@" and some check after the encode...

2. Is it possible to quickly validate the UTF-8 encoding correctness of a language pack and fix the current set of language packs? I.e possible check through iconv comand:

# iconv -f UTF-8 blocktype.externalvideo.php.orig -o /dev/null
iconv: illegal input sequence at position 1328

So, supposing the file to be wrongly encoded using ISO-8859-1 (è<->hex E8), this could be a way of fixing the IT file

# iconv -f ISO-8859-1 blocktype.externalvideo.php.orig -o blocktype.externalvideo.php.utf8

TIA