/
readme.txt
119 lines (82 loc) · 4.85 KB
/
readme.txt
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
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
Dragonfly
Directories:
src: source code for dragonfly client
docs: documentation that is not auto-generated
tools: tools needed for building/distributing/testing
Developing Dragonfly:
When working on the code base you should use the "dragonkeeper"
tool. See the README file for dragonkeeper for more information:
http://bitbucket.org/scope/dragonkeeper/
Building Dragonfly:
*Note:* It is not necessary to build Dragonfly during development. See above.
Building dragonfly means concatenating resources together (js and css),
adding a license preamble to files, generating inline data-uri
versions of graphics, minifying, translating and doing keyword
substitution on the source files to insert version number and so on.
The build is done using the dfbuild.py tool. This requires python. Currently
it will only work in python 2.5 and 2.6, but minimal changes are required to fix this
if necessary. The module depends on the jsminify module for minifying
scripts. This is bundled with dfbuild.
dfbuild lives in the tools directory in the repository.
This is the command line help for dfbuild:
Usage: dfbuild.py [options] source destination
Destination can be either a directory or a zip file
Options:
-h, --help show this help message and exit
-c, --no-concat Do NOT concatenate script and css
-l, --no-license Do NOT append license file to js and css. (license is
taken from $cwd/include-license.txt
-k key=value, --keyword=key=value
A key/value pair. All instances of key will be
replaced by value in all files. More than one
key/value is allowed by adding more -k switches
-d, --delete Delete the destination before copying to it. Makes
sure that there are no files left over from previous
builds. Is destructive!
-t, --translate Apply translation changes to the finished build
-s, --no-string-check
Don't check validity of strings before building
-e, --no-enc-check Don't check encoding of files before building
-m, --minify Minify the sources
-u, --no-data-uri Don't generate data URIs for images in css
-b SET_BASE, --set-base=SET_BASE
Set a base url in the document. The value of the
setting is the realative root in the destination path.
E.g. a the value "app" with the destination "<some
loca path>/app/core-2-5" will set the base url to
"/app/core-2-5/". The purpose is to ba able to rewrite
urls without breaking other urls of the rewritten
document, e.g. handling all different core version on
the "/app/" path without redirects.
Suitable command line for release builds
pyhton tools/dfbuild.py -l include-license.txt -m -t -s -k "$dfversion$=Dragonfly testversion" -k "$revdate$=<todays datetime>" src build
Running test builds of dragonfly:
Open opera:config#DeveloperTools|DeveloperToolsURL and set the url to the
path to the dragonfly build to use.
Updating translations:
NOTE: While translated strings are placed in the src/ui-strings
directory, that is not the authoritative location for translations.
Strings are kept in Opera's translation infrastructure, which uses .po
files. These are not publicly available.
As a consequence, we can not integrate string fixes from volunteers by
simply merging new versions of the JavaScript string files. The
strings will need to be whetted by the translations team and
integrated into the Opera translation infrastructure.
To work with translations, you will need Python installed. You will also need
polib, which can be installed e.g. by:
pip install polib
The translation workflow is as follows:
1. While developing and testing, new string are added to src/ui-strings/ui_strings-en.js
2. Before a release, Dragonfly has to be localized. This is handled by the
translations team. To request translations from the translations team, a so
called DB file has to be created. To generate this file, run the js2strings.py
script, like so:
python ./tools/js2strings.py ./src/ui-strings/ui_strings-en.js > <db_file>
3. File a BTS task in the TRN project with the DB file attached, CCing relevant people.
4. When strings are returned from the translations team, they are in PO format,
and needs to be converted back to JS files. This is done like so:
- Check out the translations from the translation team to a directory
- Run po2js.py as follows:
python ./tools/po2js.py -d <po translations checkout dir> ./src/ui-strings
- If there were new languages added, the according JS file needs to be added
to ./src/client.xml