Parse error in french lang file Parse error in french lang file
 

News:

CPG Release 1.6.26
Correct PHP8.2 issues with user and language managers.
Additional fixes for PHP 8.2
Correct PHP8 error with SMF 2.0 bridge.
Correct IPTC supplimental category parsing.
Download and info HERE

Main Menu

Parse error in french lang file

Started by Nibbler, December 29, 2004, 06:11:19 PM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

Nibbler

'notice1' => '(*) en fonction de la configuration des %sgroupes%s', (do not translate %s!)

Why was that commited without being at least briefly tested ?

Joachim Müller

Quote from: Nibbler on December 29, 2004, 06:11:19 PMWhy was that commited without being at least briefly tested ?
simply lack of time - people send me language file updates all the time, I just can't/won't check them, as the cpg1.3.x language files within the devel branch are anyway just there as "proof of concept" for the language fallback feature, they need to be replaced with "real" 1.4 language files before the release. Keeping track of all the languages, the suggested fixes etc. is a very time-consuming thing; that's why I asked Olivier if he could take over this issue, hopefully untested language file commits will not happen in the future.
I'm sorry if this has caused you trouble, should I completely roll back the fixes to french.php I committed lately or will you fix the parse error and commit?

Joachim

Nibbler

I'm afraid to touch lang files for fear of messing up the encoding, it just seems odd to commit untested files.

chtito

I will handle the language files updates. I have missed this mistake because i use the utf-8 version and it had not the mistake... Edited: Oh! then i'm probably the culprit... Gaugau is really not to blame because it really is cumbersome to maintain these language files...

Anyway, the parse error is fixed.

cheers!

== Olivier
Vous pouvez poser vos questions en français sur le forum francophone !

Nibbler

Thanks Olivier.

On a side note - it is vital to check user contributed lang files, otherwise anyone could hide a print_r($CONFIG) in their translation for some obscure language and compromise everyone's galleries in one small step.

Joachim Müller

@Olivier: in the past I mainly updated the "regular" language files and created the utf-8 encoded ones based on the "regular" ones. In most cases I created the utf-8 versions when committing any changes, but there may be exceptions I'm not aware of. If translations differ, you should use the "regular" ones and create utf-8 versions based on them.

@Tommy: I didn't commit language files updates sent by others as they were, but did a diff view and copy'n pasted the updates from the new contributions into the existing files, visually comparing the code I copied, so it's very unlikely I copied a backdoor in the code over. The "usual" resulting errors when not testing every aspect of changes in the language files are parse errors or JavaScript errors because of unescaped single quotes.

Joachim

Joachim Müller

Olivier, has this been fixed?

Joachim