blob: f48721ee8546613b488273b3f97885c31fae12c0 (
plain)
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
|
# HACKING -*- org -*-
#+TITLE: Hacking notes for PINentry
#+STARTUP: showall
* No ChangeLog files
Do not write ChangeLog files for Pinentry. We put change
information only in the GIT commit log, and generate a top-level
ChangeLog file from logs at "make dist" time. As such, there are
strict requirements on the form of the commit log messages.
* Commit log requirements
Your commit log should always start with a one-line summary, the
second line should be blank, and the remaining lines are usually
ChangeLog-style entries for all affected files. However, it's fine
-- even recommended -- to write a few lines of prose describing the
change, when the summary and ChangeLog entries don't give enough of
the big picture. Omit the leading TABs that you're used to seeing
in a "real" ChangeLog file, but keep the maximum line length at 72
or smaller, so that the generated ChangeLog lines, each with its
leading TAB, will not exceed 80 columns.
For more infomration please check the HACHING file from the GnuPG
project.
* String translation
Pinentry does not not require any translation files because it
expects that all strings are provided localized by the caller. This
is due to the design constraint to keep the tool simple and also to
make sure that translations match those of GnuPG.
The available translated strings can be found in GnuPG, file
agent/call-pinentry, function start_pinentry. If a string is not
available the Pinentry code uses a default as a fallback. However,
it is highly suggested to provide Pinentry with translated strings.
|
