blahma

I can appreciate the annoyance, blahma. If you would please post here all 6 characters which are not allowed I will do my best to ensure they are allowed in the future. Thanks. Many thanks, OpinioNate, for the quick feedback! I am glad there is someone willing to discuss the issue, since so far I have heard from the Czech geocacher community only clues of such kind that there is nobody at Groundspeak interested in getting this fixed, which however I myself could not really believe. I made a slight mistake in my previous post: The characters of Czech alphabet which do not appear correctly in listings are not six, but seven, and they of course appear in two variants each (uppercase and lowercase), which makes a total of fourteen characters. The respective character codes are: U+010C & #268; Č Latin Capital Letter C with caron U+010D & #269; č Latin Small Letter C with caron U+010E & #270; Ď Latin Capital Letter D with caron U+010F & #271; Ď Latin Small Letter D with caron U+011A & #282; Ě Latin Capital Letter E with caron U+011B & #283; ě Latin Small Letter E with caron U+0147 & #327; Ň Latin Capital Letter N with caron U+0148 & #328; ň Latin Small Letter N with caron U+0158 & #344; Ř Latin Capital Letter R with caron U+0159 & #345; ř Latin Small Letter R with caron U+0164 & #356; Ť Latin Capital Letter T with caron U+0165 & #357; ť Latin Small Letter T with caron U+016E & #366; Ů Latin Capital Letter U with ring above U+016F & #367; ů Latin Small Letter U with ring above A straight-forward solution would naturally be "permitting" these characters in the same way like all other Czech characters already do get accepted at the moment. If perhaps the listings are being stored in Unicode, then I guess it would be enough to explicitely accept these characters instead of perform diacritics stripping on them. But since the problem appears to me to be something related just to the character set used for storing the data, I dare suggesting a quick work-around which should be easy to implement and should render those letters usable with just a bit of effort from the author. Such a solution is accepting the HTML entities for the respective characters (I have listed those entities in the second column, although with an extra space between & and # in order to prevent it from being displayed incorrectly in this forum). Presently, all HTML entities in a cache listing seem to get automatically converted into the character they represent, which may not be a desirable behavior, particularly in respect to this particular issue. I am willing to stay in touch with you and help in any way I could in this matter, and I am sure that you would get a lot of cheer from the Czech geocachers community if you succeed in getting this working in one way or the other.

I'm glad to see some progress occurring at the GC.com website. At the same time, however, some of the changes seem to have had negative influence on some existing cache listings. In the few of my caches, for instance, I have been utilizing one of the recently fixed issues as a walk-around for being able to provide my listing text with proper Czech characters (which, if typed literally, get corrupted by the GC.com server). Now, this walk-around does not work anymore, and as a result I am again denied the use of certain letters of the alphabet in my listings. The provisional solution, employed by most of Czech geocachers, is to replace the problematic letters with similarly looking ones from the English alphabet. However, this seems ugly, decreases the readibility of the text, and at some occasions it may even create confusion. The situation may be perfectly compared to such a one when six selected letters of the English alphabet would not be allowed in listings. I realize that full international support in listing text must be a difficult issue. However, in this case I see a solution (a little walk-around, actually) which exists out there, is very easy, secure, and would require no changes in database structure at all: The only step necessary for fixing this bug is to allow the use of HTML entities with listing text (e.g. č) by turning off the feature which now converts these to the respective Unicode character, which later gets crippled, however. Preserving the HTML entity would present a solution for the problem. I will appreciate any feedback on this topic. Apparently, there are lot of people concerned by the discussed issue.

Saluton! Ĉu estas pluraj geokaŝludantoj kiuj parolas Esperanton? Kiuj estas?! Mi ĵus finfine ekaktivis en tiu ĉi hobio (delonge mi sciis pri ĝi, sed malfacilis por mi serĉi, sen aliro al GPS-ilo) kaj ni nun eĉ jam havas teameton de junaj esperantistoj en Brno, Ĉeĥio, kie mi studas! Jam iam antaŭe, mi kreis la artikolon http://eo.wikipedia.org/wiki/Geoka%C5%9Dado en la Vikipedio en Esperanto. Ĝi laŭ mi ĝis nun estas la plej signifa reta informilo pri geokaŝado en Esperanto. Mi tamen kredas la ludon aparte interesa, des pli por homoj scivolemaj kaj vojaĝemaj, kiaj esperantistoj kutime estas. Jam kelkaj miaj esperantistaj amikoj, al kiuj mi rakontis pri ĝi, tre ekinteresiĝis. Ĉu eble indus iel kunlaborigi la ekzistantajn esperantistajn ludantojn kaj prepari iun inform-disvastigan strategion? Kaj certe ankaŭ nia internacia lingvo mem havas kapablon aldoni interesan kroman dimenzion al la ludo. Ne nur ke en nia teamo ni nun uzas esperanton por interkomuniki pri serĉado kiam en la ĉirkaŭaĵo troviĝas eksteruloj, sed ankaŭ ni jam havas ideon iam starigi kaŝujon kun temo "Esperanto". Kaj ankaŭ ekzemple cirkuligo de vojaĝskaraboj povus esti oportune helpita de esperantistoj, kaj male ties cirkulado povus atesti pri la internacieco kaj tutmondeco de la esperanto-movado. Do, kiuj vi ceteraj estas? Kaj kion vi pensas pri tiuj ideoj? Amike, Marek Blahuš prezidanto de Ĉeĥa Esperanto-Junularo