Gewoon met een if checken welke taal de gebruiker heeft..

Waarom gebruik je nog de oude mysql-functiebibliotheek, en geen mysql[u]i[u] of PDO?
In PHP 7 zal dit script niet meer werken namelijk om dat de oude mysql-functies uit de mysql-bibliotheek verwijderd zijn.

Waar sla je nu de taal van de gebruiker op?

Het is waarschijnlijk niet zo simpel als een kwestie van de taal checken. Als [messages] een tabel is waarin standaard (systeem)berichten staan opgeslagen dan ligt in principe de inhoud, op een aantal variabelen na, vast.

Het probleem van "taalafhankelijkheid" blijft bij de bovenstaande opzet ook bestaan. Immers, het bericht wordt opgeslagen in een specifieke taal. Wat als de gebruiker nu overstapt van nederlands naar engels of andersom? De berichten staan dan nog steeds in de eerder geselecteerde taal?

Taal is ook een beetje weerbarstig. Lang niet altijd hebben de variabele onderdelen dezelfde volgorde. De "placeholders" voor de variabele delen van zo'n bericht staan dus mogelijk op verschillende plaatsen in verschillende talen. Een volgorde staat dus niet op voorhand vast.

Wat ik waarschijnlijk zou doen, als je het goed wilt aanpakken, is taalafhankelijke templates maken die horen bij eenzelfde bericht. Vervolgens heb je een lijst van placeholders/variabelen met specifieke waarden die je hier in kunt plakken. Dit zijn dan die $breakout, $breakout1, $breakout2 etc.. Deze zou ik dan wel fatsoenlijke namen geven die identificeren waar ze voor staan.

In je messages tabel zou je dan bijvoorbeeld (ben hier niet helemaal over uit) kunnen refereren aan het bericht en de variabelen sla je dan bijvoorbeeld geserialiseerd op. En afhankelijk van de dan geselecteerde taal geef je het bericht weer wat hoort bij die taal. Eventueel zou je dat bericht dan ook kunnen cachen in de juiste taal ofzo, zodat deze niet elke keer helemaal on-the-fly opgebouwd hoeft te worden.

Mijn algemene advies is eigenlijk: denk wat meer/beter na over hoe je omgaat met meertaligheid in een applicatie.

Je bent nu namelijk al een tabel aan het gebruiken/vullen (en waarschijnlijk zijn er meer van dit soort situaties) en nu merk je dat de schoen niet (meer) past. Dat is dan een indicatie dat je terug moet naar de tekentafel en een slimmere aanpak zou moeten verzinnen. En liefst eentje die meteen al dit soort taalgerelateerde problemen plat slaat.

als je het zo wilt. Gewoon checken welke taal de gebruiker heeft...

Ik moet al even nadenken om het nog op deze manier te doen, omdat ik meestal PDO gebruik als database connectie.
Ik raad inderdaad ook zeer zwaar aan om alles van mysql_ in je code om te vormen naar PDO of eventueel mysqli_

Op de oude manier denk ik aan iets als volgt:

<?php
//je vorige code
$sql=mysql_query("SELECT `lang` FROM `[users]` WHERE `login`='HIER-DE-LOGIN-NAAR-WIE-JE-WIL-STUREN'");
$tmp=mysql_fetch_object($sql);
$taalOntvanger=$tmp->lang;


/*
Je kan nu deze taal gebruiken om een even een ander taalbestand te laden (terug je include).
Na het versturen laad je terug het originele taalbestand op basis van de al bestaande $lang variabele.
*/

Mja als $lang de file is die voor de huidige gebruiker is ingeladen dan is dat niet noodzakelijkerwijs de taal van de ontvanger?
Je zult dus -op zijn minst- (tijdelijk) naar een andere taal moeten schakelen. En dat zou het laden van een nieuwe set vertalingen moeten triggeren ofzo, of je moet daar op een of andere manier de beschikking over hebben.

Snap je op een functioneel niveau wat er moet gebeuren? Verwoord het eens voor jezelf. Dit is dan meteen een specificatie van de code die je moet schrijven om dit te bereiken. Hoe je dat dan precies doet maakt in beginsel niet zoveel uit, maar ik zou je wel aanraden om hier op den duur een soort van generieke oplossing voor te verzinnen, en niet al deze taalgerelateerde problemen ad hoc op te lossen anders wordt je code in een mum van tijd een (nog) grote(re) brei.

Overigens:

$tmp=$sql->fetch_assoc();
$taalOntvanger=$tmp->lang;

Ga eens goed na wat je hier doet? Je haalt $tmp op als een associatief array. $tmp is dus een array, geen object. $tmp vervolgens behandelen als een object ($tmp->lang) gaat dus sowieso niet werken.

Je kan mij hier ook voor inhuren hoor.
Op een kwartiertje is dat gefixed :-p

Het is niet de properste methode, maar zou moeten werken:

$sql=$mysqli->query("SELECT `lang` FROM `[users]` WHERE `id`='".$mysqli->real_escape_string($id)."'");
$tmp=$sql->fetch_object($sql);
$taalOntvanger=$tmp->lang; 


include("lang/".$taalOntvanger.".php");




$sql = "INSERT INTO `[messages]`(`time`,`IP`,`from`,`to`,`read`,`subject`,`message`) VALUES (
 NOW(),
 '".$_SERVER['REMOTE_ADDR']."',
 'afzender',
 '".$man->login."',
 '0',
 'invite',
 '".$mysqli->real_escape_string($lang['invitation_sent'])."'
)";
$mysqli->query($sql);




if (empty($lang)) {
$lang = substr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 0, 2);
}
switch ($lang)
 {
 case "nl" :
 include("lang/nl.php");
 break;
 case "en" :
 include("lang/en.php");
 break;
 case "de" :
 include("lang/de.php");
 break;
 default :
 include("lang/en.php");
 break;
}

Het bovenstaande werkt waarschijnlijk prima, maar de vraag is of je zo alle taalgerelateerde zaken wilt aanvliegen. Als je een volledig meertalige site / applicatie wilt maken is het misschien handiger/verstandiger om een wat generiekere aanpak te hanteren.

Zou moeten werken. Wat heb je nu zelf geprobeerd

*Dit bericht is verwijderd*

Citaat van tkzone

Het werkt helaas niet, blijft nog steeds de bericht versturen in de taal van verzender.

"Het werkt niet". WAT werkt er niet? Het resultaat is duidelijk, maar wat is de oorzaak hiervan?

Misschien is het ook handig om een stramien voor ontwikkeling en debugging te hebben?

Bijvoorbeeld een "flag" voor een debug/developer modus. Gooi dit ergens in een config:

<?php
define('DEBUG_MODE', true);
?>

De waarde (true of false) zou je van diverse dingen af kunnen laten hangen zoals host, user, of wat dan ook.

En zet vervolgens aan het begin van je code het volgende:

<?php
if (DEBUG_MODE) {
    // developer mode
    error_reporting(E_ALL);
    ini_set('display_startup_errors', true);
    // dump errors to screen
    ini_set('display_errors', 'stdout');
} else {
    // live mode
    error_reporting(E_ALL);
    ini_set('display_startup_errors', false);
    ini_set('display_errors', false);
    // write errors to log
    ini_set('log_errors', true);
    ini_set('error_log', '/path/to/logs/error.log');
}
?>

Zo heb je één schakelaar (DEBUG_MODE) die bepaalt wat er met je errors gebeurt.

Naarmate je code langer wordt moet je echt meer en meer gaan nadenken over een goede architectuur. Dit vormt het fundament van je applicatie. Als dit fundament al gammel is dan stort het geheel op den duur in als je alleen maar dingen blijft bijmetselen.

Overigens, de beste manier om te leren programmeren is de fouten bestuderen en vervolgens uitzoeken hoe dingen in elkaar zitten. Anders blijf je tegen een "black box" aanturen zonder dat je begrijpt wat er gebeurt. Maar je moet dan om te beginnen van je code signalen ontvangen (en vervolgens kunnen interpreteren) over wat er misgaat. Hiervoor zijn de bovenstaande settings.

NB: een include genereert geen foutmelding, enkel een "warning". Het kan dus best zo zijn dat jouw (include) paden niet goed zijn, niet goed staan ingesteld, of beide.

Zie ook dit topic van je:
https://www.phphulp.nl/php/forum/topi…cript/103356/1/

1 ding. Je hebt dus 'read' en je plaatst dat als 0. Dus ongelezen. Je kan dat gewoon weglaten in in je DB standaardwaarde 0 geven.