The comment linked in that issue seems to suggest more than just passing the current language.

The apps can already be localized, it is a matter of having a menu inside the app where the user can pick some other language, and obviously the app needs to provide such translations. Passing the current language is unneeded, as it is already available through navigator.language in javascript. If navigator.language doesn't reflect the current language, then that should be an issue by itself.

It looks like that comment is after some method for sharing the translations already available for Hive, so the apps can reuse them as much as possible. No amount of translations will ever be enough for all the possible apps, but some of the common translated strings could be reused and at least reduce some trivial effort on the translations there. I'm not sure if this actually helps, as it might induce to apps half-translated which doesn't improve the user experience.

The apps can already be localized, it is a matter of having a menu inside the app where the user can pick some other language, and obviously the app needs to provide such translations. Passing the current language is unneeded, as it is already available through navigator.language in javascript. If navigator.language doesn't reflect the current language, then that should be an issue by itself.

It looks like that comment is after some method for sharing the translations already available for Hive, so the apps can reuse them as much as possible. No amount of translations will ever be enough for all the possible apps, but some of the common translated strings could be reused and at least reduce some trivial effort on the translations there. I'm not sure if this actually helps, as it might induce to apps half-translated which doesn't improve the user experience.

No, it wasn't about passing any actual translated strings from Hive to apps, that wouldn't make much sense as you say. This is specifically about passing info about the locale currently used in the app. I haven't thought about navigator.language, that can probably be useful for now, but I'm guessing it doesn't always reflect the Hive locale exactly - especially if Hive doesn't currently have a translation for the language you've chosen in the system preferences.

The apps can already be localized, it is a matter of having a menu inside the app where the user can pick some other language, and obviously the app needs to provide such translations. Passing the current language is unneeded, as it is already available through navigator.language in javascript. If navigator.language doesn't reflect the current language, then that should be an issue by itself.

It looks like that comment is after some method for sharing the translations already available for Hive, so the apps can reuse them as much as possible. No amount of translations will ever be enough for all the possible apps, but some of the common translated strings could be reused and at least reduce some trivial effort on the translations there. I'm not sure if this actually helps, as it might induce to apps half-translated which doesn't improve the user experience.

No, it wasn't about passing any actual translated strings from Hive to apps, that wouldn't make much sense as you say.

Uhm I just said it was, right in the last comment. You need an API for letting the apps access the locales, obviously you won't pass the entire files on every application start.

Uhm I just said it was, right in the last comment. You need an API for letting the apps access the locales, obviously you won't pass the entire files on every application start.

Ok, now I'm confused, but anyway here's what we're planning:

- there will be locale information in the JS API, so the app will be able to check if the whole UI is displayed e.g. in French or in German, and if it includes its own translations for its labels inside the app bundle, it can use some kind of JS i18n library to change the language of the labels

- there (probably) won't be any API that passes any specific translated strings from Hive to the app through the API, because I think there's no way we can prepare any generic set of labels that would be reusable in any significant amount of apps and would cover all copy needed in those apps, and that would probably be more work than it's worth anyway

Hi, I'm just trying to get my head around what this is, and I'm sorry I haven't read too much yet. As I understand it, the hive app is an app which is or will be a bitcoin wallet, but also offers an API for people to create their own bitcoin related games which can be played with the bitcoins in the users wallet. Is that right or am I way off?

Hi, I'm just trying to get my head around what this is, and I'm sorry I haven't read too much yet. As I understand it, the hive app is an app which is or will be a bitcoin wallet, but also offers an API for people to create their own bitcoin related games which can be played with the bitcoins in the users wallet. Is that right or am I way off?

Any kind of app, as long as you can do it using javascript, html, and css. It is just a webkit browser embedded there.

Hi, I'm just trying to get my head around what this is, and I'm sorry I haven't read too much yet. As I understand it, the hive app is an app which is or will be a bitcoin wallet, but also offers an API for people to create their own bitcoin related games which can be played with the bitcoins in the users wallet. Is that right or am I way off?

Hive is a Bitcoin wallet for Mac OS X

Hive wallet also has a API, allowing developers to build apps that live inside the wallet itself, making it easy for Hive users to interact with Bitcoin services directly. Since it's HTML/CSS/JS-based, anything that can run in the browser can be an app.

apps now run on http://app_name.hiveapp/ instead of http://localhost/app_name - this was changed to prevent apps from reading each other's cookies (but if possible, please don't hardcode the address, just take it from location.href, as we may need to change it again in the future)

you can now safely use cookies to persist data between sessions (just remember to set a persistent cookie, not a session cookie, i.e. with an expiration date set)

localStorage does NOT work properly right now and you should not rely on it

there are bitcoin.VERSION and bitcoin.BUILD_NUMBER properties if you need to check the Hive version

if you are relying on the fact that Hive disables origin policy check for XHR requests, please don't do that - we'll be removing this in the future (and there will be an API method added instead that will proxy the request for you)

Also, a few things you might not be aware of:

Hive has a Webkit inspector enabled, so in any app you can right-click and choose "Inspect" to get access to the JS console

for easier development, you can replace an archived app bundle in ~/Library/Application Support/Hive/Applications with an unpacked directory with the same name, and the app will work exactly the same

Since we are warning people at every turn to be careful with our wallet until it leaves "alpha" stage, there are probably not a lot. However, we will be peeling off those labels very soon and making a wider push.

Still, we do get emails every day asking for support, and we see in those that a lot of people are totally ignoring our warnings and sending thousands of dollars worth of Bitcoin using Hive. We don't have any kind of "calling home" feature to tally data, so we cannot be too specific just yet.