Kategoria: IT-ala (marraskuu 2012)

I've had this problem for a long time: I install an application or play a game and it guesses what language I want it to show me. I live in Finland and Finnish is my native language. But I like using English in many places. I know it very well. And I like consistency. Think about this whole thing from someone else's point of view. Someone, who just happens to live in Finland but doesn't understand a word of it. It's not an easy language to pick up just like that.

And yes, I have a Finnish keyboard and Finnish language as the written language and that explains some of these, but not all and it's still about consistency above all.

When my Windows is installed with English language, I'd like the applications to realize that it's not a mistake. It's actually how I like it. You know, there is a Finnish version available. I could install that if I wanted. I don't want to. So why do applications think I actually want them to be in Finnish when every other thing is in English?

This has mostly been a problem with Open Source Software. There also is the additional problem that the translations are many times quite horrible. I once got so annoyed that I translated one again myself since the person who did it before didn't bother to use the correct translations for database vocabulary but decided to invent their own. Agh.

7-Zip is one of the applications that forces Finnish upon me. And its translations are not-so-great. Context menu gets options like "To unarchive here..." etc. No. Change of language.

Another one is Filezilla. It's quite bad in other ways too, but I've gotten used to it so can't be bothered to replace it. But it needs to not be in Finnish when I install it!

Apple's iTunes etc also want to be in Finnish. The installer especially is idiotic: it knows that I want English when I update it. It even shows it to me. But the installer is still in Finnish, every time.

The solution to these is most of the time just to change the language. But some don't have a language selection! Previously I had to delete all translation files from Inkscape to force it to be in English. Many people don't know how!

The latest idiocy is from Ubisoft. Assassin's Creed 3. Start it up. It's in Finnish. Ok, settings. There is option for spoken language and subtitles. Not for UI. What the heck? I have to lie in my Xbox settings that I'm in United Kingdom to get the UI to English? And yes, this was the "fix" given by Ubisoft support too. So the 6% of people living in Finland that have Swedish as their native language, you're now living in Sweden. And the quarter of a million other language speaking people, you don't live here either. That's Ubisoft's take on this matter.

Switching Xbox location settings (mind you: not language settings, once again, they're English on my console but that is not considered by Ubisoft) might make it to use illegal radio frequencies for Wifi and is just totally stupid. Why should I change my settings so that Ubisoft doesn't have to make a language selection? What about the USA? Do they force English to all the millions Spanish speakers or do they get to select? I must check this out...

One Windows 8 application worked nicely for some time until the developers decided to add a French version. What could go wrong... Naturally I wasn't ever given the chance to use the English version again, probably because all people in Finland or with some Finnish settings can magically understand French. FI is much nearer to FR than EN, right? Needless to say I stopped using the application that instant.

Gigantti/Elkjøp also have an application for Windows 8 which has some deals you can't get anywhere else. Once again, there is a location setting in Windows. Do they use it? No. They use the language of the UI. So, once again, the 6% of Finnish people now live in Sweden and that's it. And I don't live in any country that has their deals, according to them. And their support response? "Change your language." And they didn't care about the fact that many people just don't want to change their UI language just because Gigantti is so lazy that they can't make a setting or detect the actual location of the user. Not to mention, once again, the over half a million people in Finland that are not Finnish speakers.

I'm sure I'm not the only one with this problem/annoyance. Or am I? I know that there are hundreds of millions of people that use their machines in their native language and live in a country where the native language is the official language. But there are many of us that either don't use the native language or don't live in a country where it's official. And some of us have even several official languages. Some have none!

So what I'd like to know is: how come would anyone be so stupid as to determine the display language based on the user's physical location or the user's physical location based on the display language? It should be counterintuitive for anyone with half a brain. Yet, it still is happening all the time.

So, please, whatever you do don't ever design a system that forces some language upon the user unless you can be damn sure they know it. If the OS is set to language X, I'd say that's a good way of guessing the user knows language X. But preferrably give them a selection upfront. It's not ok to make people guess which menu option means settings or language selection in a foreign language.

Problems, Problems...

On October 31st I got an email from Nokia about this new and shiny Premium Developer program. I also received an email stating that "You will receive an email soon with a code that entitles you to a free year’s membership in the Nokia Premium Developer Program." Well, it's almost a month later and I've yet to receive it. And what I've heard, others have received theirs.

So I emailed them two weeks after this asking when I'd get the token. No reply still. Nothing.

I tweeted to @nokiadeveloper about this, they said they'll send the word that someone will contact me. Nothing after a week.

So is this how things are handled or is it just me that's receiving the silent treatment? It's not the first cockup from Nokia with me. Last time I was in the developer program and was supposed to get a Lumia 800. When I couldn't order it and asked what's going on, they said "oops, for some reason your membership had expired and naturally you couldn't do anything, we fixed it, sorry." That was not nice, but they fixed it when I contacted them at least.

The Actual Program

The actual Premium Developer program boasts that with $99 per year you'll get up to €1,500 in value! Sounds great, right? But hey, what will you get? Sorry to say that most of that "value" is one service and if you don't need Buddy's notification service (I kinda don't see the point since you can send notifications yourself, but hey, to each their own), the maximum value is $300. Still not bad, right? The rest is two Nokia support cases, Telerik controls and a year of Microsoft membership.

So I think the point here is that they're trying to make people think about just the money. $1,500 is a lot, but who will actually receive that? Who will send million requests per month through Buddy? Not that many.

But I'm not saying it's a bad thing to buy: $99 is the Microsoft membership fee. With $99 Nokia fee you get that and more. So in any case you're not losing money. And I'm sure that's how they thought about it.

So, go on, get the membership. At least you're getting $99 worth of stuff with the $99, so it's not bad. But for the $1,500... Well, I'd like to hear from someone that thinks they'll actually use those notification API calls.

(Sorry, Nokia, I just can't do positive publishings about your stuff when you don't give me anything positive to say. But I'm positive about Lumia 920, haven't had a chance to test it out though, so can't write about it.)

Huom: kirjoituksessa ei puhuta Finvoicen validiudesta itse XML-spesifikaation kanssa, vaan laajemmin XML-määritysten ja hyvien tapojen mukaisesti. Kun jo tuolla eräs ehti viilata pilkkua :) Toki Finvoicen tuotokset menevät XML-parserista läpi, mutta ne eivät ole "hengen mukaisia."

Vilkaisin taas Finvoicen speksejä, kun pitäisi toteuttaa laskun tulostus sitä kautta. Jo vuosia sitten kritisoin tuota ja kyselin tekijöiltä miksi ihmeessä asiat on tehty aivan päin mäntyä. Vastaus oli "tuli vähän kiire." En tajua miten kiire selittää sen, ettei otettu edes perusasioita osaavia ihmisiä tekemään määrittelyä.

Ne, jotka eivät ole Finvoiceen tutustuneet, se on XML-muotoisten laskutietojen välitykseen tarkoitettu standardi. XML taas on rakenteellisten tietojen välitykseen tarkoitettu kieli. Huomatkaa sana "rakenteellisten." Tätä meinaan Finvoicen speksaajat eivät ymmärtäneet.

Normaalisti, jos määriteltäisi vaikkapa katuosoite, sille voidaan antaa täginimi StreetName. Tämä voidaan sitten laittaa vaikkapa Sender-tägin alle, tai Recipient, tai minkä vain. Tiedetään aina, että tuossa on osoite. Miten tekivät Finvoicen speksaajat? Unohtivat kokonaan, että kyse on rakenteellisesta ja tekivät useita eri tägejä osoitteelle. Löytyy SellerStreetName ja tietysti erikseen BuyerStreetName, puhumattakaan DeliveryStreetName:sta. Eli rikottiin XML:n perusidea. Nämä tägit laitetaan tietysti esimerkiksi DeliveryPostalAddressDetails-tägin alle, joka on DeliveryPartyDetails-tägin alla.

Eli siis oikea tapa olisi tämä:

<Seller>
  <Address>
    <StreetName>Koulukatu 1</StreetName>
  </Address>
</Seller>

Onko tuota vaikea lukea ja ymmärtää, että tuo on myyjän katuosoite? Ei. Mutta Finvoicessa asia tehdään näin:

<SellerPartyDetails>
<SellerPostalAddressDetails>
<SellerStreetName>Koulukatu 1</SellerStreetName>
</SellerPostalAddressDetails>
</SellerPartyDetails>

Tässä siis käytetään turhan pitkiä tägejä, ei hyväksikäytetä XML:n sisäänrakennettua rakenteellisuuta eikä anneta mahdollisuutta määrittää suoraan, että StreetName:lla pitää olla tietty esitysmuoto. Tehdään sitten kolme esitysmuotomääritystä ja yritetään muistaa päivittää kaikki kolme, kun muutoksia tulee.

Mitä tämä sitten tarkoittaa? Sitä, että jos haluat jotenkin käyttää osoitetietoja, sinun pitää määritellä asioita moneen kertaan. Sen sijaan, että tietäisit StreetNamen olevan aina katuosoite, pitää nyt määrittää kolme tägiä, jotka ovat katuosoite.

Samoin jatkuva Seller/Buyer/Delivery-alkuosien toitotus on turhaa. Se vain aiheuttaa ylimääräistä tietoliikennettä ja sotkee tiedonkäsittelyä. Oletan, että nämä on haluttu siksi, että ihminen voisi tietoja lukea. Mutta se ei ole tarpeen, sillä ihminen osaa lukea rakenteellista tietoa, kunhan se esitetään vaikkapa sisennettynä. Josta pääsemmekin seuraavaan ongelmaan.

Sisennyksiä ei saa tehdä! Speksi sanoo selvästi: "Jokaisen rivin pitää alkaa "<"-merkillä ja päättyä ">"-merkkiin." Miksi ihmeessä? XML-parserit osaavat kyllä lukea oikeamuotoista XML:ää. Taasko halutaan, että ihminen voi lukea tiedostoa suoraan? Sitten voi käyttää työkalua, joka muotoilee sen näin, jos halutaan.

Myöskin merkistö on pakotettu: "Finvoice-sanomilla käytetään ISO-8859-15-merkistöä." Eli en voi määritellä kyrillisillä merkeillä tietoja, en kanjeilla, en mitenkään. Miksen? Ei sillä että itse heti tarvitsisin, mutta koko maailma ei pyöri tuon merkistön ympärillä. XML-parserit osaavat kyllä lukea eri merkistöjä ongelmitta. Eivätkö tekijät osaa?

Lukuarvot pitää myös esittää XML-määritysten vastaisina. XML-serialisoinnissa käytetään yleisesti lukuarvoissa pistettä desimaalierottimena. Finvoice vaatii pilkun. Myöskin desimaalimäärät on pakotettu, ihan vain "jotta verkkopankissa e-laskusta voidaan muodostaa maksuehdotus." Pankin järjestelmätkö eivät osaa lukea standardimukaista numerotietoa, ainoastaan tietyllä tavalla määritettyä? Toteutettiin kokonainen Finvoice-palikka, muttei osattaisi tehdä asioita oikein?

Laskurivejä voi myös olla monenlaisia. Laskurivillä ei välttämättä tarvitse olla edes mitään laskurivitietoja! Kaikki ovat silti InvoiceRow. Miksei näitä voitu tehdä omilla tägeillään? "Laskurivi" voi olla vaikkapa vapaamuotoista tekstiä tai välisumma. Ei näin.

Myöskin 2.0-esimerkkitiedostossa on paljon kohtia, joista ei soveltamisohjeessa puhuta mitään. Pitää siis lukea skeematiedostoa ja muita dokumentteja ja arpoa, sen sijaan, että olisi tehty kunnon dokumentaatio.

Miksi meillä on mm EpiBfiPartyDetails sekä EpiBeneficiaryPartyDetails, jotka molemmat kertovat samoista tiedoista?

Miksi esimerkissä on 0 % ALVilla 622,68 euron summa 1500 eurosta? Kopypaste toiminut...

Viitenumeron pitää olla tämän speksin mukaan joko eurooppalainen vaihtelevanpituuksinen tai SPYn mukainen, mutta väkisin 20 numeroa. Harva käyttää 20-numeroisia viitteitä, mutta nyt niihin on sitten pakko laittaa etunollat?

EpiCharge-tägin sisällön pituus pitää olla nolla. Esimerkissä sillä on sisältöä, eli esimerkkilasku ei ole validi. Myöskin esimerkkilasku on kotimaan lasku, silti maksuehto on SEPAn mukainen SLEV eikä kotimainen SHA. Tietenkään en dokumentaatiosta löytänyt tarkemmin tietoa mitä nämä SHA/OUR/SLEV/BEN tarkoittavat, mutta sellaisia arvoja sinne voi laittaa. Ja kuka ihme keksi tägin EpiDateOptionDate?

Pikku huvituksena oli myös yksikköesimerkkinä oleva kwh/h...

Huvittavaa on myös esimerkkilaskussa oleva teksti: "Tavoitteena on, että Finvoice-laskumallia käyttävät yritykset voivat hyödyntää laskun konekielisesti käsiteltäviä tietoja suoraan omissa taloushallinnon järjestelmissä ilman ylimääräisiä muunnoksia. Yhteisestä mallista hyötyy kaikki osapuolet." Niin, miten tästä nyt sitten ilman ylimääräisiä muunnoksia käytetään tietoja hyväksi, kun tiedot on ripoteltu huonosti tägitettyinä, speksinvastaisilla lukuarvoilla ja käytetään yhtä tägiä osoittamaan laskurivejä, seliterivejä ja välisummia? Tämä vain vaikeuttaa tietojen käsittelyä suoraan, ilman muunnoksia. Mutta onko porukassa ketään, joka tämän ymmärtäisi? Ei.

Toki voisi kuvitella, että kun kerran alunperin tehtiin väärin, pakko jatkaa niin. Ei ole. Nyt kun kerran tuli versio 2.0, miksei tähän korjattu asioita? Kuitenkin joudutaan muuttamaan laskun muodostamista ja lukemista, joten samalla vaivalla olisi korjattu nämä asiat ja oikeasti tehty yleismaailmallinen standardi. Nyt tyydyttiin laajentamaan olemassaolevaa ja tekemään asiat vieläkin päin mäntyä. Ja näin varmasti jatkossakin.

Tässä vain taas muutama asia, joihin törmäsin heti määritystä selatessani. Enemmänkin löytyisi, jos kaivaisi. Ja pakko kai on, kun muuten ei saa toteutettua määritystä. Nyt vain pitää muistaa pakottaa XML-tulostus juuri oikeanlaiseksi, kun Pankkiyhdistyksen väki ei osaa muuten lukea tietoja. XML-parserit kyllä osaisivat ilman mitään ongelmia.

Hei Pankkiyhdistys! Ensi kerralla kun teette jotain tällaista, ottakaa vaikka minut konsultoimaan asiassa. Voin vaikka tulla ilmaiseksi niin ei tarvitse sitten tuhlata aikaa puolivillaisten sähellysten kanssa touhuamiseen. Säästän joka tapauksessa aikaa ja rahaa sillä. Kiitos!

Since Microsoft released the Windows Phone 8 SDK, I've had some problems. First, the emulator requires Hyper-V and SLAT support, which is not available on my trusty old Latitude D830. And I'm sure there are lots of people that don't have the newest generation CPUs in their machines. That means they can't test their apps on the emulator. Naturally on device works, but that's not always the best way.

Another problem was pointed out by a friend: there are lots of developers that have done apps for iOS and might want to port those to WP8. They can't just start Windows on Parallels and use the emulator there. VMware supports SLAT virtualization (at least on Windows, not sure about OS X), so it should be possible to run Windows 8 under VMware and the emulator would work.

Personally I run VMware virtual machines on my desktop and if I install the Hyper-V role, I can't run VMware. This is a problem. So I either have to reboot every time I want to run the emulator or install another Windows 8 in a virtual machine and run the emulator there. Both are cumbersome.

I kinda understand why Microsoft made it this way. They have a strong virtualization platform and as we've seen with iOS and Symbian emulators, it's not the same running the app compiled to x86 and on top of another OS. There are problems that are not on the device or that don't appear on the emulator. It's much better to run the actual ROM image that is on the device. But to require SLAT and disallow other virtualization at the same time is not nice.

Hoping MS could fix this problem, but I think it might not happen. I've been thinking about getting a new laptop for some time and this is one more reason for it. But since my old machine works so well and the only thing I'm needing is basically more memory, I haven't done it yet. Maybe it's time.

It'd help if Nokia would send a Lumia 920 and Microsoft would send a Surface... ;)