including Brazilian Portuguese language for the system bonfire

Signed-off-by: adias <adias@sowebsites.com.br>
Merge branch 'develop' of git://github.com/ci-bonfire/Bonfire into develop
Upgrade Brazilian Portuguese language
admin theme: remove unused ajax loader (which has missing alt text)

Unused code suffers from bitrot.  (E.g. who knows if mobile__header.php
should include the loader?)

And the loader creates warnings on every page, about the image with no alt
text.  (That's not using any a11y tool; just the HTML5 validator).

Setting alt text might be an improvement, but there's more to providing
a11y than that when DOM manipulation is involved.  In that sense, the
current non-ajax admin interface is rather easier to reason about than the
old one :).
user_form: remove empty alert box

My fault (d13c4c06).
ui: remove unsafe DOM manipulation of form

Firefox "bfcache" (back-forward) caches the DOM state of pages in the
browser history.  This provides convenient performance and usability,
but it means you can't use naive DOM manipulation in a submit handler.
(I haven't tried to work out whether there's a event you can sensibly catch
to undo the manipulation; it's simpler to just rip out the JS nonsense :).


Here's the issue:
1. add a test shortcut
2. click its "remove" button
3. click the browser "back" button
 => deleted shortcut reappears
4. click "save"
 => Expected behaviour: deleted shortcut is recreated
 => Actual behaviour: error message complaining that the shortcut could not
    be deleted
database controller: remove dead line

In order for this to take effect it should be set_block() instead of set(),
the controller would have to use a non-default layout, and there would have
to actually be a file core_modules/database/views/admin/sidebar.php.
database controller: nitpick the optimize() error message
database controller: fix DROP

(It would claim success, but fail to delete the table(s).  Let's at least
fix the latter problem).

I guess it's understandable if people haven't been eagerly testing this
feature :D.
Fix the "save" keyboard shortcut (#645) and avoid using "name=submit"

Why:

- #645: I broke "ctrl+s: Save any form in the admin area."

  > The JS keys off name="submit".  In some forms I had changed this to
  > name="save".  [Because] I misliked having some forms with name="submit"
  > to represent "save", and an alternate submit button with name="delete"
  > ...

- ctrl+s should not perform dangerous actions like deleting tables, because
  the user may have intended to invoke a harmless browser shortcut.

- One page - the emailer settings - had two buttons with name="submit", the
  settings page and the test form.  There was no comment to indicate what
  behaviour was expected when hitting ctrl+s here.

- name="submit" should not be used, because it masks the DOM submit()
  method on the form.

  http://stackoverflow.com/questions/3571328/form-submit-button-will-not-submit-when-name-of-button-is-submit

What:

 - Change the shortcut to key off name="save".

 - Use name="save" for all "save" buttons.  I include "create" as well,
   but I do not include more general actions, such as deleting tables.

 - Set new names for all the other submit buttons :).

 - Update controllers to accept the new names.
Add post_key_exists(), use it to improve code consistency

This avoids the uncommented use of isset() and $_POST, particularly
in the output of the module builder.
Language fix v1.
Cleaned up to use sprintf.
Fixed lang-keys, indent too.
database controller: remove old delete() method
database controller: backups(): remove Windows-centric no-op

Having write permission to a file doesn't mean you can delete it.

Presumably this was designed with Windows in mind - it's trying to check
whether another instance of Bonfire has opened the file.  But you can't
delete open files on Windows anyway.
database controller: refactor backups()
Translation for french version,  fixed using "lang()" where there are static string And fixed error Title table on user views.

- partial translation -> must be know if technical words must be translate like "Controller, Models, Views, or Database, Form Input. In my opinion, we could let technical words in english because it's current usage of using english in programming
- In order to translated breadcrumb, add new rules, see above

Translated :
- application_lang
- database_lang
- /core_modules/activities/
- /core_modules/builder/

Add new entries on application_lang to next translation breadcrumb which is ommited

--
New rules : Add new entries on each language file of each module (and core_module) like $lang['module_name'] = 'Module Name'; in order to use on breadcrumb translation
If node breadcrumb is a context, this translation is on application_lang $lang['bf_context_NAMEofCONTEXT'] and must be add on New Context)
--

Add fix forgotten "lang()" using :
- Activities core modules :
  > /core_modules/activities/controllers/reports.php
  > /core_modules/activities/views/reports/index.php
- Breadcrumb function on Template :
  > /librairies/template.php

Add a test on the user language to add a special particle just for french version in special case:
- /core_modules/activities/views/reports/view.php

Add fix thead error (module -> user) on top_user table :
- /core_modules/activities/views/reports/index.php
Remove some direct uses of $_POST
users profile editor: fix setting username (including issue #661)

than the form uses to display the field).

Also, don't silently ignore the strings '0' and ''.

This will match the behaviour of register() and the admin interface.
users module: password and display name fields are strings, never FALSE

These fields are always present in the form, so input->post() will never
return FALSE.  However the current test would silently ignore the string
'0'.  Avoid the code-smell by using an exact comparison to the empty
string.