1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
<p align="center">
<img src="src/assets/icons/512x512.png" width="200px"><br>
<a href="FAQ.md">FAQ</a> |
<a href="CONTRIBUTING.md">Contributing</a> |
<a href="https://github.com/0neGal/viper/releases">Releases</a><br>
</p>
## Contributing
Generally speaking, as Viper is a FOSS (GPLv3) project any bug reports, pull requests, or other types of help, forks are appreciated, but preferably unless it's off-topic to the goals of Viper, it would be far more appreciated if you were to make a pull request, or similar, and get it upstream.
**HOWEVER:** Before opening issues and pull requests and similar, please do read our <a href="CODE_OF_CONDUCT.md">code of conduct</a>, as to avoid issues.
### General contributions
If you're contributing, please follow <a href="CODE_OF_CONDUCT.md">code of conduct</a> as mentioned above, along with that please do not change code style. Viper uses double quotes, 1 tab per indent, and semicolons at the end of function calls.
`//` for 1-2 lines of comments, max of 72 comment text width always, preferably if textwidth outside of comments also exceeds 72 characters if possible find a way to make it fit within 72 characters. Lower case comments are also generally preferred when using `//`
`/* */` is useful in some cases, refer to the code example below.
`() => {}` is also preferred over `function () {}` when possible.
Single use functions are also generally discouraged, if a function is used once there's no need to make it a function.
As shown below below:
```js
function foo(bar) {
/*
This is a very long comment, however, it does not exceed 72
characters, and instead wraps down so it fits nicely on a small
screen without having to mess with soft-wrapping or similar.
*/
console.log(bar);
// and this is a comment using "//",
// which is two lines long
}
// examples of () => {}
setInterval(() => {
foo("I RUN EVERY 1000MS");
}, 1000)
```
With the above information you should be able to comfortably make contributions without too much hassle...
### Localizing/Translating
Viper has a very simple i18n system, please read below for instructions.
#### Language file
The language file will be a file inside the `src/lang/` folder, name it according to the [ISO 3166-1 Alpha-2 standard](https://en.m.wikipedia.org/wiki/ISO_3166-1_alpha-2) in lowercase, meaning English = `en.json`, Spanish = `es.json`, French = `fr.json`, and so on.
Everything inside the file is pretty straight forward, the only special one is the `lang.title` string, please set this to `<language in english> - <language in native language>`, meaning for French it's, `French - Français`. This will be shown inside the language selection screen.
If you don't feel like editing a JSON file and copying keys back and forwards from other complete language files, then you're in luck, because `scripts/langs.js` help with this exact problem. Simply make sure a valid localization file already exists, meaning it could have just `{}` inside it. Then after that you can use the language script to manage it:
```sh
$ npm install
$ npm run langs:localize
```
You'll be prompted to select a language to edit, then if there are missing keys you'll be prompted for whether you just want to add those keys or if you want to edit all keys. After that you'll get a list of all the keys available, you'll simply select any of them, then you'll be prompted for the value for the key, then hit <kbd>Enter</kbd> when you're done, and you'll be put right back to the list of keys as before. You'll then edit as needed, when you're done select `Save changes`, you're changes will then be written to the localization file and it'll automatically be formatted for you.
To sum it up:
1. Make sure a parseable JSON localization file exists in `src/lang/`
2. Run `npm run langs:localize` (after `npm install`)
3. Select your desired language
4. Select the key you want to add/change
5. Edit it as you wish
6. Save whenever your done
7. Commit your changes!
If you do happen to manually edit your localization files remember to run the following commands before committing and pushing changes:
```sh
$ npm install
$ npm langs:check # verifies the files are parseable and not missing keys
$ npm langs:format # formats and sorts the file for you
```
#### Maintainers file
If you're okay with being contacted in the future when new strings have to be localized please put your contact links inside this file, under your language. Preferably put the link to your GitHub profile as that is the easiest contact method for obvious reasons.
|
