From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Fischer To: development@lists.ipfire.org Subject: Re: Aw: Re: [PATCH] Syntax fixes in several CGIs Date: Wed, 30 Dec 2020 08:31:25 +0100 Message-ID: <676b8f9d-16f7-a0a4-4a39-fc0d3ec08ce1@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5093666605997841405==" List-Id: --===============5093666605997841405== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, On 29.12.2020 20:52, Bernhard Bitsch wrote: >=20 >> ... >=20 > First just an excuse. I wrote 'hash tag' without thinking thoroughly about = the term. ;) > I meant 'hash key'. If this key consists of just one word ( no spaces ) it = is sufficient just to use this word as key. > Your example uses a string with spaces, thus you must "stringify" the key. Ok, got it. >> But at the risk of sounding silly: I still got translation and >> designation(?) problems, sorry. >> >> Hash tag =3D '$Lang::tr{'update'}'!? >> >> Stringifying =3D ??? >> >=20 > See above. In case of translation hash %Lang::tr many keys are composed of = several words, requesting the string representation 'this is a key'. > The example > value =3D '$Lang::tr{'update'}' > could also read > value =3D '$Lang::tr{"update"}' > not using the same delimiters for the string update. > Remember, a regex automaton usually doesn't count, thus it cannot distingui= sh start and end delimeters. The second ' is treated as the end of the string. >=20 > Hope, this makes my suggestion a bit clearer. Yep. Thanks a lot. ;-) I hope I can remember this next time... Best, Matthias P.S.: I know, why I have specialized on hardware - software is more complicated. ;-) --===============5093666605997841405==--