Final Branding

CONTRIBUTING.md

@@ -1,4 +1,4 @@
-# Contributing to Monero
+# Contributing to uPlexa
 
 A good way to help is to test, and report bugs. See
 [How to Report Bugs Effectively (by Simon Tatham)](https://www.chiark.greenend.org.uk/~sgtatham/bugs.html)
@@ -15,7 +15,7 @@ of software solid and usable.
 Patches are preferably to be sent via a Github pull request. If that
 can't be done, patches in "git format-patch" format can be sent
 (eg, posted to fpaste.org with a long enough timeout and a link
-posted to #monero-dev on irc.freenode.net).
+posted to #help in Discord).
 
 Patches should be self contained. A good rule of thumb is to have
 one patch per separate issue, feature, or logical change. Also, no
@@ -55,7 +55,7 @@ the previous paragraph is here.
 ## License
 
 Copyright (c) 2009-2015 Pieter Hintjens.
-Copyright (c) 2017-2018 The Monero Project.
+Copyright (c) 2017-2018 uPlexa.
 
 This Specification is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.
 
@@ -67,10 +67,9 @@ You should have received a copy of the GNU General Public License along with thi
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
 
-The "Monero Maintainer Team" is defined in this document as the following users:
-- fluffypony
-- moneromooo
-- hyc
+The "uPlexa Maintainer Team" is defined in this document as the following users:
+- QuantumL3aper
+- Blk
 
 ## Goals
 
@@ -126,17 +125,17 @@ C4 is meant to provide a reusable optimal collaboration model for open source so
 - To request changes, a user SHOULD log an issue on the project Platform issue tracker.
 - The user or Contributor SHOULD write the issue by describing the problem they face or observe.
 - The user or Contributor SHOULD seek consensus on the accuracy of their observation, and the value of solving the problem.
-- Users SHALL NOT log feature requests, ideas, or suggestions unrelated to Monero code or Monero's dependency code or Monero's potential/future dependency code or research which successfully implements Monero.
+- Users SHALL NOT log feature requests, ideas, or suggestions unrelated to uPlexa code or uPlexa's dependency code or uPlexa's potential/future dependency code or research which successfully implements uPlexa.
 - Users SHALL NOT log any solutions to problems (verifiable or hypothetical) of which are not explicitly documented and/or not provable and/or cannot be reasonably proven.
 - Thus, the release history of the project SHALL be a list of meaningful issues logged and solved.
 - To work on an issue, a Contributor SHALL fork the project repository and then work on their forked repository.
 - To submit a patch, a Contributor SHALL create a Platform pull request back to the project.
 - A Contributor SHALL NOT commit changes directly to the project.
 - To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere.
 - To accept or reject a patch, a Maintainer SHALL use the Platform interface.
-- Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 30 days) or unless urgent as defined by the Monero Maintainers Team.
+- Maintainers SHOULD NOT merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers for an extended period (more than 30 days) or unless urgent as defined by the uPlexa Maintainers Team.
 - Maintainers SHALL NOT make value judgments on correct patches unless the Maintainer (as may happen in rare circumstances) is a core code developer.
-- Maintainers MUST NOT merge pull requests in less than 168 hours (1 week) unless deemed urgent by at least 2 people from the Monero Maintainer Team.
+- Maintainers MUST NOT merge pull requests in less than 168 hours (1 week) unless deemed urgent by at least 2 people from the uPlexa Maintainer Team.
 - The Contributor MAY tag an issue as "Ready" after making a pull request for the issue.
 - The user who created an issue SHOULD close the issue after checking the patch is successful.
 - Maintainers SHOULD ask for improvements to incorrect patches and SHOULD reject incorrect patches if the Contributor does not respond constructively.

README.i18n.md

@@ -1,44 +1,6 @@
 uPlexa daemon internationalization
 ==================================
 
-The Monero command line tools can be translated in various languages. If you wish to contribute and need help/support, contact the Monero team, come chat on `#translations` (Discord) - https://discord.gg/a7mAQwJ
+The uPlexa command line tools can be translated in various languages. If you wish to contribute and need help/support, contact the uPlexa team, come chat on `#translations` (Discord) - https://discord.gg/a7mAQwJ
 
-In order to use the same translation workflow as the [Monero Core GUI](https://github.com/monero-project/monero-core), they use Qt Linguist translation files.  However, to avoid the dependencies on Qt this normally implies, they use a custom loader to read those files at runtime.
-
-### Tools for translators
-
-In order to create, update or build translations files, you need to have Qt tools installed. For translating, you need either the **Qt Linguist GUI** ([part of Qt Creator](https://www.qt.io/download) or a [3rd-party standalone version](https://github.com/lelegard/qtlinguist-installers/releases)), or another tool that supports Qt ts files, such as Transifex.  The files are XML, so they can be edited in any plain text editor if needed.
-
-### Creating / modifying translations
-
-You do not need anything from Qt in order to use the final translations.
-
-To update ts files after changing source code:
-
-    ./utils/translations/update-translations.sh
-
-To add a new language, eg Spanish (ISO code es):
-
-    cp translations/monero.ts translations/monero_es.ts
-
-To edit translations for Spanish:
-
-    linguist translations/monero_es.ts
-
-To build translations after modifying them:
-
-    ./utils/translations/build-translations.sh
-
-To test a translation:
-
-    LANG=es ./build/release/bin/monero-wallet-cli
-
-To add new translatable strings in the source code:
-
-Use the `tr(string)` function if possible. If the code is in a class, and this class doesn't already have a `tr()` static function, add one, which uses a context named after what `lupdate` uses for the context, usually the fully qualified class name (eg, `cryptonote::simple_wallet`).  If you need to use `tr()` in code that's not in a class, you can use the fully qualified version (eg, `simple_wallet::tr`) of the one matching the context you want. Use `QT_TRANSLATE_NOOP(string)` if you want to specify a context manually.
-
-If you're getting messages of the form:
-
-    Class 'cryptonote::simple_wallet' lacks Q_OBJECT macro
-
-all is fine, we don't actually need that here.
+More information coming soon.