Clearly mailmen would just be expected to use their phones to decode the addresses on demand, because everything is supposed to require a phone and an internet connection these days.
A bit more realistically, the address could be printed on a sticker by the sorting machine, the way address redirections are handled.
> A bit more realistically, the address could be printed on a sticker by the sorting machine, the way address redirections are handled.
Fun fact: PostNL already does this with 100% of the mail processed. The first step in the sorting process is to OCR the address, generate a "KIX" barcode[0], and print that on the letter using special ink if not already present. It's not intended to be user-readable, but anyone with a smartphone can trivially decode the unique destination address from it.
For a mail/parcel carrier relabeling anything is (somewhat surprisingly) a significant added cost (and there is not that much of margin), so they will do everything in their power to not do that unless absolutely necessary.
PostNL relabels approximately all parcels addressed to me (I almost always have to change either the delivery date or location to one convenient to me), completely free of charge.
Free of charge to you and free of charge to the sender. Which is exactly my point, for PostNL it is a sunk cost and if that will happen for significant amount of their consignments it would be an issue.
Yeah here in Portugal we have a ton of those too. Each municipality has its own cm-<name>.pt domain, but there some exceptions. For example, Lisbon's domain redirects to lisboa.pt, and while no other major city I know does this, almost all of them have separate website and domain without the cm- part.
I'm not sure how old you are but congratulations on living this long without encoutering the unmitigated hell of Apple plist files.
I remember seeing when I first started using OSX 10.0 about two decades ago and my reaction was about the same as yours. At least now `plutil` can output (and read) JSON, along with lots of other enhancements to make it slightly less insane to use.
Oh it's not that bad, plus it's just an on-disk serialization format. You use it like you would Python's pickle by dumping/loading from NSDictionary/NSArray.
It's ordered, typed, can be validated by schema, and just takes the format you would write naturally and removes the boilerplate because your primitive collections in plist world aren't trees they're dicts and arrays just like in JSON.
Now imagine that the workspace/project format for the defacto IDE for all Apple related stuff uses this exact same format, mixed with some random binary blobs and it keeps track of all project settings and file structure. Now imagine merging that in your VCS of choice whenever another team member makes any change to any of the aforementioned things.
Good news! You don't have to imagine! You can live this fever dream yourself by using Xcode.
How a company with that much money can unironically produce such dumpster fire garbage of a so-called IDE is beyond my comprehension.
> Now imagine that the workspace/project format for the defacto IDE for all Apple related stuff uses this exact same format
It doesn’t. Xcode project files are something that look a bit like a cross between JSON and an INI file. This is unofficial documentation showing what it looks like:
That isn’t a property list; it’s something inherited from Project Builder from NeXTSTEP, which Xcode was originally based upon. Xcode project files would be a lot easier to deal with if they were property list files, because they are a standard, documented format with official tools to work with them. The Xcode project file format isn’t officially documented and doesn’t have generic manipulation tools like plutil.
Maybe you are mixing the project file up with the Info.plist file? That is a property list file, but its purpose is to tell the operating system about the application. It’s not the Xcode project file.
This is one of the unexpected externalities of Apple’s walled garden. You may not deal with Xcode directly if you use Xamarin et al. then some poor soul somewhere has to sacrifice their first born every year when Xcode received an update.
If Apple allowed other App Stores, they would have to make Xcode not suck.
> The order of the words is hardcoded, with “added” preceding the date. This would be incorrect in many languages, from Dutch (“1 januari toegevoegd”)
This is simply not true. Since English and Dutch are both Germanic languages they largely work the same way. Saying "Toegevoegd: 1 januari" would be just fine. By using "1 januari toevoegd" you're syntactically changing the sentence.
1 januari toegevoegd sounds like you're adding the date. If you're going to write it as a sentence it ought to have something like "Op 1 januari", and in that case it actually doesn't matter whether you put the toegevoegd before or after "op 1 januari". But I agree, nothing wrong with "Toegevoegd: 1 januari".
reply