diff --git a/language-snippets.ent b/language-snippets.ent
index 70be27efa..30e21eaaf 100644
--- a/language-snippets.ent
+++ b/language-snippets.ent
@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
-<!-- EN-Revision: 0b93d1fa3a46529bbec57ed1454cf19dd98ae42d Maintainer: shein Status: ready -->
+<!-- EN-Revision: a88922dd2590d9a4ec268606ce99d6f726ef8ffb Maintainer: shein Status: ready -->
 <!-- Reviewed: yes -->
 <!-- $Revision$ -->
 <!-- Keep 'em sorted -->
@@ -457,8 +457,23 @@ dbm_identifier</parameter></term><listitem><para>Идентификатор со
 
 <!-- JSON notes -->
 
-<!ENTITY json.implementation.superset '<note xmlns="http://docbook.org/ns/docbook"><para>PHP реализует надмножество JSON - также кодируя и декодируя скалярные типы и &null;. Оригинальный JSON поддерживает эти значения только в случае, если они находятся внутри массива или объекта.
-</para></note>'>
+<!ENTITY json.implementation.superset '
+ <note xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink">
+  <para>
+   PHP реализует надмножество JSON, который описан в первоначальном
+   <link xlink:href="&url.rfc;4627">RFC 4627</link>, - также кодируя и декодируя скалярные типы и &null;.
+   RFC 4627 поддерживает эти значения только в случае, 
+  если они находятся внутри массива или объекта.
+  </para>
+  <para>
+   И хотя это надмножество согласуется с расширенным определением 
+   "JSON текста" из новых <link xlink:href="&url.rfc;7159">RFC 7159</link> 
+   (который старается заменить собой RFC 4627) и <link xlink:href="&url.json.ecma;">ECMA-404</link>, 
+   это все равно может приводить к проблемам совместимости со старыми парсерами JSON, которые
+    строго придерживаются RFC 4627 с кодированием скалярных значений.
+  </para>
+ </note>
+'>
 
 <!-- cURL notes -->