Hi PGV Translators,
Currently some of you have been using HTML entities to encode diacritics in the language files. I would like to ask that you no long use the HTML entities such as è to represent .
The entities will only work when the text is viewed as HTML. This means that in other technologies, the entities will not get converted. This will especially be a problem for the new PDF reports. It also causes problems trying to automatically convert characters to upper and lower case.
PhpGedView will fully support the UTF-8 encoding of these characters and this is the prefered way to encode the language files. It should be pretty simple for you to do a search and replace in your language files to replace all of the entities with their UTF-8 encoding.
One use of entities that causes problems is the Hebrew dates. Since the Hebrew dates are generated in the functions.php that everyone uses I used entities so that we could ignore the BOM issue caused by different editors. Language file translators are aware of the BOM issue and therefore most language files have no problem. Do you have any suggestions that would allow me to convert them from the html entities that wouldn't be disruptive to development?
We could put the UTF-8 encoding for the Hebrew date characters in the functions.php file. Most of the developers use Crimson Editor to edit the files now, which won't mess up the encodings or add the BOM.
However it would probably be better to make an enter in the language hebrew file for them and use the $pgv_lang array to reference them. This is what I have done for converting numbers to chinese.
How can I reference the Hebrew lang file when the user is using English?
If my understanding of your code is correct for a chineese user you reference the users current lang file:
$zhnum = $pgv_lang["10"].$zhnum;
Hebrew dates can appear regardles of the users current language so I would have to reference(psudo c0de):
$myHebrewMonth = HEBREW_LANG_FILE.$pgv_lang["Tisray"];
I didn't think about the Hebrew Lang files not being loaded.
To put them in the hebrew language files you would have to put them in a different language array and require the hebrew language file whenever you need it. So maybe it would be best to just include it in the functions.php file. The encodings should be safe.
Done for french language files.
See patches section.
I attempted to change the hebrew dates in functions.php (nothing checked in) but ran into a problem with the " that can be contained in Hebrew dates. I assume that the pdf would need it in the \" format while " is needed for html.
Would we need a conversion done to change such entities?
A second thing I tried to change is the fact that Hebrew dates are returned wrapped in a <span dir="rtl" .... tag
I tried removing the span and allow the browser to render it using the standard bidi algorithm but it messed up the position of the ' and " in dates. A workaround to this would involve use of righlt-left and left-right markers (‎ ‏) but then again this would pose a problem for PDF.
besides the quote issue I guess that the PDF renderer can stip off the <span (no idea how it will render RTL text though).
Any ideas would be welcome.
These files have lines with typo's in the HTML entities that will defy an initial search/replace operation.
phpGedView31:languages:configure_help.es-ar.php"; Line 69:
$pgv_lang["PGV_DATABASE_help"] = "Indica a phpGedView que tipo de almacenamiento de datos quiere utilizar para importar el archivo GedCom en el sistema. Seleccione 'Índices' para utilizar archivos í:ndice guardados en el directorio index, o s
phpGedView31:languages:lang.ru.php"; Line 76:
$pgv_lang["private"] = "??㖵 Ŗ<=?? (privé);";
phpGedView31:languages:configure_help.es.php"; Line 65:
$pgv_lang["PGV_DATABASE_help"] = "Esto le dice al phpGedView que tipo de sistema de almacenamiento de datos quiere utilizar para importar el archivo GEDCOM. Seleccione 'Índices' para utilizar archivos í:ndice guardados en el directorio i
phpGedView31:languages:lang.es.php"; Line 617:
$pgv_lang["privacy_write_error"]= "ERROR!!! No se puede escribir en el archivo [#PRIVACY_MODULE#].<br />Compruebe los permisos de escritura para este archivo.<br />Los permisos podrán ser restitu&iacite;dos una vez se haya sobreescrito el archivo."
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.