Thanks for the answer!

If I understand this correctly, if I want to add a language to my installation of elgg, I have to first request it using Transifex, where possibly it would have to be approved by someone, and then added to next release, before I can use it?

Normally, this would not be a problem, and I wholeheartedly support giving back to the community in such a way, however, the problem is that the language that I need to add does not actually exist, and as such, I'm not sure it would be accepted. To be precise, my client wishes to make a social networking site targeting people from ex-Yugoslavia living abroad and wants to provide a single language ("Yugoslavian") instead of separate versions (serbian, croatian, bosnian...), since these languages are completely mutally intelligible and, linguistically, are the same language.

Ok, your use case is indeed an exception. It is possible to achieve your goal also by adding the files manually.

The syntax is nowadays a bit different. In languages/yu.php:

<?php

return array(
    'foo' => 'bar',
);

You may have a syntax error somewhere in your translations file. Test this by temporarily removing all the strings from the language file, and checking if the error goes away.

@Juho: could the error be caused because this custom language would have a language code ("yu") not included in the array of allowed language codes? I'm not sure if this array is only checked when making a new Elgg release or if the array is also checked for example when the cache is built up / refreshed.

@Miloš Milutinović: If the problem is caused by a language code / language file name not known to Elgg you could name you files instead as one of the known languages (e.g. using the name of Serbian, or Croatian, or Bosnian...) to see if the translations are used then. Of course, you would have to select a language you don't intend to use otherwise. For getting the "correct" language name in the language selection you would have to override the corresponding language string for this language, too, e.g. when using the Croatian language code for naming your files you would have to add the line

"hr" => "Yugoslavian",

within one of your custom language files (or rather replace the corresponding line in your translation of Elgg's main language file).

Or you could test if it helps to add your custom language code to the array of allowed language codes in engine/classes/Elgg/I18n/Translator.php (just adding it in the array returned in the function getAllLanguageCodes()). If this would fix the issue you would have to make sure to add it each time after upgrading Elgg though.

I haven't used contexts before, but I think I've got it - so I just do this to register my plugin hook:

elgg_register_plugin_hook_handler('config', 'htmlawed', 'alter_htmlawed_for_webservices', 500);

And I found this in web services plugin, so I just need to check for 'api' context:

elgg_set_context('api');

The only remaining thing is to find a htmlawed config that makes him do nothing. I'll probably try this out, thanks for help!

I think in an Elgg installation it's insane to disable Htmlawed filtering on any content. There are just too many plugins available that assume content is safe HTML.

Using something like elgg_html_decode seems the least bad solution.

FYI, if you use contexts, use push/pop instead of set.

This particular issue is the by-product of weird stuff that is done with the input in the web-services plugin, which instead of relying on input sanitization, builds input into a query string and then parses it. 

https://github.com/Elgg/Elgg/blob/2.x/mod/web_services/lib/web_services.php#L233