Feedback on the update process (Page 2 of 4)

Well, maybe, but it still COULD HAVE BEEN translated.. and the cost in attempting to convert it is nothing for the update process.

Note for those who want to use the code i provided : it needs to be placed within the "if ($start_at == 0)" block (as we need to do it only once).

Actually, the word 'guest' should be put in the lang pack, rather than hardcoded in install.php...

It was good. Should have instructions though (I managed to figure it out on my own though)

Mpok: Then you point out where it's being used hardcoded so we can make sure it uses the language files, you don't unilaterally decide to edit the hardcoded text. Otherwise, your changes only benefit you and not the wider community. They can also potentially cause problems down the line, as you see here.
That doesn't change the fact that you shouldn't be translating strings in the database though. And even if we tweaked db_update.php to convert the guest user (which requires changing one line, not adding eight), that wouldn't change the fact that the text shouldn't be converted in the first place.

??? You mean changing '2' to '1' ? The conversion made in the general loop is not neither applicable nor sufficient for guest user. The fields needed to be converted ARE different from common users. So u need a special treatment, and then, more lines (only thing is that the three fields are likely to be the same, so the code can be reduced from the one i've provided, but not in lines, counting commentary one).

But in rev. 1478, this string has not been taken in it..

Thanks to suppose we're THE ONLY ones to attempt to get a REAL localization (means got translated EVEN the hardcoded values), but i'm not sure we're the only ones..
And ur not sincere (as a developer) : u encounter 3 times in a row the same word u have to translate, and u just translate the first one ? (note: u didn't give me the answer at "Are these values being used somewhere ?")

Once more, this WOULD'NT HAVE HAPPENED IF ONLY THE SCRIPT WAS "localizing" (mean used lang files, which WAS NOT THE CASE). So please, don't reproach us things we're not responsible.

I DID pointed u in my previous message at least 2 of these 'hardcoded values'...

And in install.php, maybe "Paul created lang/English/install.php", but NONE of the actual strings are taken from the lang file.

Which is why you point these things out to us, so we can fix them.

If you can point me to some other groups that are distributing translated versions with the same problem, I'd be happy to chastise them as well. It has nothing to do with you being "the only ones" (or not) and everything to do with how you went about dealing with hardcoded strings.

I would translate just the username, yes. Nothing else is displayed publicly (and I doubt even the username is). That's why I think translating this stuff was so silly: you might as well translate the database schema and the GPL preamble at the top of the code.
And you should be able to tell me if the strings are used anywhere: since PunBB.fr translated the strings, they should know what those translations changed.

And once more, when we don't localize things, you should be reporting them to us so we can do so. You shouldn't be modifying the core files in order to create a language pack (although I know PunBB.fr created its own parallel version to get a "complete" translation of certain untranslatable features in 1.2, like the admin panel and install.php). The developers are not the ones creating localizations in most cases: thus, we can only know if something is needed if you tell us.

And as Bekko said, there's really no point in continuing this conversation. If you find hardcoded strings, tell us so we can deal with them. The database update script likely won't deal with mistranslated strings unless we find that it causes an issue and that a great number of people are affected by it. End of story.

Huh? I'm not completely sure what you're trying to say, but the database update script is supposed to convert all PunBB data to UTF-8.

Did you do that conversion with the version of db_update.php from SVN? If not, it would be great if you could try it again and see if that fixes your problem.
If it doesn't, it would be great if you could send either Rickard or me a copy of your 1.2 database to work with to try to track down the issue.

For anyone curious, the issue was not with the conversion process but with the MySQL dblayer.

Did you delete the cache file after that?

And an unknown cookie_name? Do you not have it set in your config.php?

I was referring to your old config file, not the one that was generated.