International Character Support

This is one for Jon @G4ZFZ

The R9U association (will be uploaded shortly) will only have Roman names to start with the option to add Cyrillic names later. I must push some more refreshes to the DB to add more non-Roman support. We can take this offline if you want to discuss adding Hangeul for Korea.

Yes, sorry about this. I suspect this regressed with a change to character set handling a while ago. I found fixing one set tended to degrade another. I’ll be taking another look at this part of SOTAwatch fairly soon since it has other issues to sort as well.

73, Jon

1 Like

I guess it is better to revive this topic, than to start a new one…

Is there any chance to have the YU association summit names correctly shown in the database? The language specific (latin) characters are still incorrectly displayed. While preparing the association data, I entered all the names correctly in the excel tables, and they show OK in the ARM, but not in the database.

9A association summit names are displayed correctly - and we use a same character set in both countries. So it definitely can be done.

73 Fric YU1WC

That sounds a reasonable request to me. I don’t know why they are not showing (especailly as I’m 2100miles from home today). It’s possible they were uploaded before I had correctly enabled non-Latin support. In which case they just need reloading. I’ll add this to the 1-dec-2017 tasks.

YU association was started just two months before the support for Unicode hence the missing diacritics. On regions that were updated since that (like IS) it is showing up properly but indeed there are a couple of regions which were never touched by annual updates and remained in the original state.

Fric, I’d be interested to know how do the YU entries look in sotamaps? They seem to be OK to my untrained eye, but then I don’t speak Serbian or Croatian…

Rob, the situation is same in sotamaps. Some characters are missing their diacritics. (Croatian association summits look OK in sotamaps)

Andy, thank you, there is no rush.

Fric, the bi ggest problem with uploading data to the database is making sure I have backups of the summits before the update so that if I break the database then I can restore it, maybe everyone loses 1 day of logs. But if the data already exists, ‘tweeking’ the data is easy and painless. I have a lightweight upload program that can only change summit names or positions without deleting or adding new summits. If the loading data exists with the correct name then it is a simple process to update just the names, 10mins max. Well 10mins if I press the right buttons!

Good to know, since I have a bunch of summits that need to have their names and/or positions corrected. At least two summits will (probably) get new reference numbers since the new (corrected) position is out of the current activation zone.

Would it be better to have both updates (unicode support, and postions/names) done simultaneously? If yes, then reschedule the tasks and wait for me to finish the postions/names updating first…

I forgot to answer this Fric. I can do the names for 1-dec-2017. But if you can wait a bit longer, then you can update the names & positions, move the badly located summits etc. When that gets verified by the summits team, it can go in possibly the 1-feb-2018 update. We don’t do an update on 1-jan-2018 due to the amount of booze consumed in GM at that time of year!

No problemo, there is no hurry! Let’s go for the February update. I should be done with the yearly association update by then.