commenting labels are broken on my live site.. any idea why?

at some point after upgrading to 1.8.14 i noticed that many of the text labels for comments were not rendering properly on my site. in locations such as latest comments widgets and the river stream.
they display as elgg language keys, e.g.:

generic_comment:on (27 days ago): update:

i noticed a big list of php warnings in the log about js language issues, and recall that some of the changes in 1.8.14 were in relation to js language files (i think they were anyway - the elgg site is loading very slowly for me presently so i'm not reaching the changelogs).. so.. anyone got a clue how i might fix this? i've disabled all the plugins except for the most basic of basic and the issue remains.

an example of the log warnings is:

2013/03/23 00:02:23 [error] 27351#0: *403265 FastCGI sent in stderr: "PHP message: PHP WARNING: 2013-03-23 01:02:22 (CET): "json_encode(): Invalid UTF-8 sequence in argument" in file /mysite/views/default/js/languages.php (line 15)" while reading response header from upstream, client: xxxxxxxxx, server:, request: "GET /ajax/view/js/languages?language=en HTTP/1.1", upstream: "fastcgi://", host: "", referrer: ""

  • Looks like json_encode() is failing due to invalid UTF-8 chars in one of your language files. Make sure language files you edited recently were all saved as UTF-8.

  • any tip on how to do that? i'm not aware of a way to do that with windoze.. or linux either.
    i have been editing language files using the coldtrick translation manager 1.2.1.

  • When I tested the Translation Editor plugin I noticed it does not save the language files in utf-8 encoding. Unfortunately, this is very likely to cause problems sooner or later...

    Bundled windows editor(s) should be able to save text files in "utf-8 without bom" encoding. Check out their save/export/encoding options and "Save as" your language files created with the Translation Editor plugin in "utf-8 without bom". Check the new saved file for possible invalid characters due to change of encoding, correct these characters and then upload the fixed language files to your server.

  • i'm using linux presently and opened 2 main files (including the core file) i gedit and saved as utf8 specifically.. that hasn't fixed the issue. i'm not sure which text editor would specifically support saving as 'utf-8 without bom'; i'm using aptana studio 3 for editing and it identified the json files as utf8 - with no mention of with or without bom. i continue!

  • @iionly plz do not give bad advice !
    Win editors don't do diddley for encoding.
    The BOM leadin chars are invisible ! so the human eye
    Will nott see the issues.
    Aptana3 is q good enuff..
    Unless ura is looking the wrong file/s ;- )

  • If the "translation manager" plugin stores translations to the DB with the wrong encoding, then no file changes are going to help you. Elgg is likely serving your pages as UTF-8 so I would assume the browser is sending UTF-8 to the server, too.

    Can you both elaborate on how this plugin works and how you're using it?

  • @Dhrup: nice to know that I'm the only one who can select encoding both in the normal Windows' editor and in WordPad when saving the text file via "Save as". Pity it does not work for anyone else but me...

    Also, I was not talking about editing/removing the invisible BOM characters but the very well visible characters like umlauts, quotation marks and other language specific special characters who could easily get corrupted when changing encoding. Well, maybe that's something that also happens only to me alone.

    Regarding saving the language files with the Translation Editor plugin I just tested it again and this time the saved language file seemed okay. I can't reproduce anymore what went wrong last time when the file was not saved in utf-8 (same computer but I've upgraded the Elgg version since then and also the Linux version just this weekend).

    @ura: can you narrow down the language file that might contain an error, i.e. does it happen also with only the en language files installed and does the error occur also with only the bundled plugins enabled?

  • @II
    Drop the sarcasm etc...
    Doe not help. To fix the only points more blame
    And concusion for the newbies...;-)
    * there's no normal windows editor but notpad which sucks,
    The bom encodin *will insert 3 invisible bytes at front of file..
    May be commonest. Cause of this utf8 issue by newbiews, they shud all more of a *code edtior
    Where Encoding if more obvious
    URAs best best might be to isolate *which file ?
    Ot where corruption happens...
    But we all need to read his code over his shoulders !;-)

  • fyi, i have tested with all but the most basic plugins disabled, so only blog, htmllawed and a couple of other core plugins were enabled and the issue remained. translation manager was disabled also.

    i have edited all the language files with translation manager - i don't know the exact process that is invoked via translation manager - only that there are many json files stored in the site's data folder, one for each plugin. the only errors i am seeing rendered in the browser relate to comments, so i believe that narrows the issue to the .en core file and i have opened and saved that in linux, with no change. so all that remains is for me to do the same in windows. the only language file i have edited directly (without translation manager) is my theme's and a couple of custom plugins which were disabled in my testing.

  • Are you editing the json files in the data directory or the language files you downloaded from the Translation Editor page from your site. Sorry, but I thought up to now that you would edit the language files. What if you (first backup and then) remove all the json files from the data directory?

    I wouldn't use the Translation Editor plugin on a productive site anyway but instead create the translation on a separate site and only install the finished language files on the productive site afterwards. What I'm wondering is why the error persists when the Translation Editor plugin is disabled. I would expect that any json files of the plugin in the data directory wouldn't be considered then.

    Do you really see the same error messages regarding invalid utf-8 sequences also with the Translation Editor plugin disabled? Do these errors - or the problem with the comments summary line - still appear with ALL 3rd party plugins INCLUDING your theme disabled and all non-English language files removed?