Armory - Discussion Thread

[jimbobway]

Ehh, I don't agree.

You have a decent shot at being the de-facto client for a worldwide currency, because I'll bet people abandon the Satoshi client in droves at the first sign of real competition.

I live in the US too, so "Armory" is the preferred spelling for me as well, and such a change is a feature that would not benefit me at all.  The least I suggest is this might come up again, especially if the code attracts other contributors interested in localizing for other languages.

I am American and I prefer "Armory".  Didn't realize there was another spelling, "Armoury".  Only English, non-US really care about this.  Asian, non-latin languages don't really care about the spelling.  I think it is better to be consistent and just keep "Armory". 

[Clipse]

Random idea: if I didn't live in the US, I might be bugged by the US spelling of "Armory", and almost would want to be able for the logo and everything to appear as "Armoury".  A low priority by all means, but something bound to be requested if it hasn't come up already.

Ehh, I don't agree.  That's like saying that that my name, "Alan" should be changed to "Allen" if I were to move to the West coast (where that spelling might be more common).  "Armory" is the name of the software.  If we were talking about a generic armory somewhere, I'd agree with you. 

Plus, I don't really want a variable-spelling name if I ever get a copyright/trademark/LLC.   That's complicated...

In most cases I hate the way american english tend to bastardise alot of "oxford english" however in the case of Armory vs Armoury I would have to choose Armory since the word Armoury looks stupid for the most part. This is perhaps when it comes to anything firearmish in life you tend to deal with american words from real life issues down to all kinds of computer games

[etotheipi]

Watching..

Any chance of switching to an MIT or BSD-style license?

btc_artist,

My licensing choice for Armory was made carefully, I believe that the AGPL best protects my interests while still making it available to all users for free.  I believe I will move in the direction you suggest, in the future, but I do not want to make that decision prematurely (as it's very difficult to change my mind after I've done it).

[ctoon6]

Random idea: if I didn't live in the US, I might be bugged by the US spelling of "Armory", and almost would want to be able for the logo and everything to appear as "Armoury".  A low priority by all means, but something bound to be requested if it hasn't come up already.

This idea is ridiculous beyond any other idea imaginable, first the oh so "scientific" metric system? Now you want us to spell words wrong?!? We will NEVER bend to you Europeans will, no matter how much better your ways of measuring things are.

[BinaryMage]

This idea is ridiculous beyond any other idea imaginable, first the oh so "scientific" metric system? Now you want us to spell words wrong?!? We will NEVER bend to you Europeans will, no matter how much better your ways of measuring things are.

I am entirely unsure whether that post was serious or not...

I seriously doubt anyone will care how the client's name is spelled, many companies misspell things wrong (eg Google != Googol) and no one ever has a problem with it.

[btc_artist]

This idea is ridiculous beyond any other idea imaginable, first the oh so "scientific" metric system? Now you want us to spell words wrong?!? We will NEVER bend to you Europeans will, no matter how much better your ways of measuring things are.

I am entirely unsure whether that post was serious or not...

I seriously doubt anyone will care how the client's name is spelled, many companies misspell things wrong (eg Google != Googol) and no one ever has a problem with it.

Plus it's not misspelled|misspellt.

[btc_artist]

Watching..

Any chance of switching to an MIT or BSD-style license?

btc_artist,

My licensing choice for Armory was made carefully, I believe that the AGPL best protects my interests while still making it available to all users for free.  I believe I will move in the direction you suggest, in the future, but I do not want to make that decision prematurely (as it's very difficult to change my mind after I've done it).

Fair enough.  Thanks for the answer.

[BinaryMage]

Plus it's not misspelled|misspellt.

True indeed. Spelled differently would have been a better way to put it.

[etotheipi]

Back on topic... I botched the sweep function when I updated zero-conf methods.  It should work properly now.  Address balances still show zero when you import them, but will be correct when you restart Armory. 

[splatster]

Is there an ETA for an OS X binary?

[jim618]

Actually, translations are something I want to support.  In fact, maybe I should make that a high priority, given your optimism about widespread adoption

The easiest way I can think of, would be to offload basically every string/message in the program, to a dictionary in a separate file (i.e. msgWarnDeleteWallet['en']="...").  Then users can replace the file with translated versions, which can be bundled with the program and selected through command-line options.  

Is there an "official" way to do/support this?  Or is my theoretical technique sufficient?

For translations work I recommend the crowdin.net platform which is:
+ free for open source projects
+ really easy to use
+ manages all the 'I have just added X number of new terms' merging
+ has automated suggestions from Microsoft and Google translate
+ you get excellent project management abilities for notifying people, track work etc.

You can CNAME your crowdin.net project URL into your site and brand it - see http://translate.multibit.org

You are free to reuse the MultiBit translation work as that is all MIT licence.   There are about 20 languages and it would get you going for the terms that are common between the two programs.   (The format is UTF in Java properties format.   Or you can also just cut and paste from the translate.multibit.org project if that is a problem).

Some of the things I found when localising (not all of which are fixed yet!)

+ Europeans use "," rather than "." as a decimal separator (and conversely "." instead of "," as a thousands separator.)
+ Date formats are different in pretty much every language.
+ Right-to-left languages mean your complete layout needs to be able to switch horizontally. (Arabic, Hebrew, Persian)
+ Never concantenate strings (e.g. amount + " BTC") as the order is different in right-to-lefts.

You have some big chunks of text on your dialogs - I would recommend putting them into your localisation files as, say, separate paragraphs.   This makes it a bit easier on the localisers when you change one sentence as only a small amount of text is marked as changed (and hence needs relocalising).

Have a look at the  http://translate.multibit.org project - it makes localising as straightforward as can be.


Also, whilst it is not strictly localisation : people using different writing systems tend to prefer their own fonts (e.g. Chinese characters look nicer in SimSun font) so when you start localising give people the option somewhere to specify what font to render the app in - or pick it up from their system settings.

[maaku]

Ehh, I don't agree.

I live in the US too, so "Armory" is the preferred spelling for me as well, and such a change is a feature that would not benefit me at all.  The least I suggest is this might come up again, especially if the code attracts other contributors interested in localizing for other languages.

Actually, translations are something I want to support.  In fact, maybe I should make that a high priority, given your optimism about widespread adoption

The easiest way I can think of, would be to offload basically every string/message in the program, to a dictionary in a separate file (i.e. msgWarnDeleteWallet['en']="...").  Then users can replace the file with translated versions, which can be bundled with the program and selected through command-line options.  

Is there an "official" way to do/support this?  Or is my theoretical technique sufficient?

"gettext" is what you are looking for.

[etotheipi]

"gettext" is what you are looking for.

Thanks!  That's exactly what I was looking for!

[Stemby]

"gettext" is what you are looking for.

gettext is a good i18n system, but Qt provides another way:

Armory is Qt-based, isn't it?

http://developer.qt.nokia.com/doc/qt-4.8/linguist-manual.html

Ciao!

[etotheipi]

Stemby,

I did look into Qt-Linguist.  However, "gettext" looks like a better solution, to me.  It looks simpler and sufficient for my project as long as translators don't mind editing text files.  You can feel free to educate me about the advantages of using Qt-Linguist, because I still have time to change my mind if there's a compelling reason

[Stemby]

Actually I don't know: gettext could be a better choice. See here.

Bye!

[etotheipi]

Seriously, I think I really fixed it this time!  New transactions are immediately found and added to the list, sent transactions are added/locked only if Satoshi client accepted them, change-outputs are available for spending right away, and all the ledgers/balances should be accurate for all wallets and addresses.  The only remaining issue is sorting of zero-conf tx in the ledger.

I updated the original post with more information about what is on the plate for alpha release.  Now that this is 99%+ fixed, I feel a TON better about alpha, and now I get some time to polish.  I'm shooting for alpha-release on Groundhog's day (hopefully, it won't be a bad experience, and then relived over-and-over forever).

If you get a chance to use/test it, please let me know if you think there's something that really needs to be implemented/fixed before alpha.  I'll get it in if I can.

Thanks for your patience! You guys are great!  (I really didn't expect zero-conf to take me 2 weeks to get it right!).
-Eto

[runeks]

I've never been a fan of storing valuable, encrypted data all over the internet, and I know how uncomfortable digital media can be.  Plus, I feel like, if it's password has "enough" entropy to be protected from interthugs, you'd have to write it down --> then you might as well just make a paper backup and keep it on your bookshelf .

How much entropy would you think is "enough"? I generated a password using random words from a dictionary containing 98,500 words. So as far as I can figure out, that's about 16.5 bits of entropy per word. Remembering 6 to 8 words from this dictionary isn't that hard actually. That's at least 100 bits of entropy; that seems to be enough to me. But yeah, at the end of the day, who knows if it's enough.

[etotheipi]

I've never been a fan of storing valuable, encrypted data all over the internet, and I know how uncomfortable digital media can be.  Plus, I feel like, if it's password has "enough" entropy to be protected from interthugs, you'd have to write it down --> then you might as well just make a paper backup and keep it on your bookshelf .

How much entropy would you think is "enough"? I generated a password using random words from a dictionary containing 98,500 words. So as far as I can figure out, that's about 16.5 bits of entropy per word. Remembering 6 to 8 words from this dictionary isn't that hard actually. That's at least 100 bits of entropy; that seems to be enough to me. But yeah, at the end of the day, who knows if it's enough.

People forget things.  I decided to use a 24-char random password for my HDD encryption on my work computer, because I thought it was cool.  No problems for a year because I'm typing it in all the time.  But then I get a new computer and come back a year later... f*** if I can remember that thing.  Plus, if something terrible happens, and you'd like your relatives to be able to recover your money... they'd probably appreciate knowing how to get to it (assuming you have a lot).

If you're protecting more than $100 worth of BTC, you should probably keep something, somewhere that helps you (or someone else) recover it when something goes wrong.  If so, you might as well just use a paper backup.  

[runeks]

^ Valid point.

I certainly don't trust the hard drive in a laptop either though. So I'd need multiple backups anyway.
At the end of the day, perhaps the safest thing indeed is to both store the wallet on a offline USB stick/laptop plus as a paper backup in case the electronics die. It should be simple to verify the validity of the paper backup by firing up a fresh live Ubuntu session on an offline computer, installing Armor, importing the private key from the paper and trying to sign a transaction with it, shuttling that transaction over to an online computer which injects it into the network to see if it's accepted.

I think you've convinced me.

Now I just need enough bitcoins to actually make me want to spend that much time on securing them. Can you help me with that too?