NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.
ntp-4.2.8p15
was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
Internationalization and Localization (GSoC 2011)
Summary
The goal of this project:
1. NTP utilities' i18n support, all programs in NTP will be ready to localization, that's, if we want NTP to support a new language, we won't need to change the program any more;
2. clear and simple data interface for localization, that is, a well arranged string list which covers the programs' output and man page and web pages, with as less redundancy as possible;
3. at least two language(non-English)'s localization of the above data; one is Chinese(my native language), the other will be selected after the goal 2 is done; I choose two here just for better testing goal 1 and goal 2;
Related Items:
Timeline
Discussion and Comments
Possible Implementation Ideas
Right now, we might have something like:
doc-section = {
ds-type = 'USAGE';
ds-format = 'mdoc';
ds-text = <<- _END_MDOC_USAGE
blah
_END_MDOC_USAGE;
};
How should we handle different languages with this?
Would
ds-text-
be a good choice?
We could put the languages one after another:
doc-section = {
ds-type = 'USAGE';
ds-format = 'mdoc';
ds-text = <<- _END_MDOC_USAGE
blah
_END_MDOC_USAGE;
ds-text-zh_CN.GB2312 = <<- _END_MDOC_USAGE
blah
_END_MDOC_USAGE;
};
Or we could try a
#include
syntax:
doc-section = {
ds-type = 'USAGE';
ds-format = 'mdoc';
#include ds-text-$LC_AGEN.usage
};
where
ds-text-zh_CN.GB2312.usage
might contain
ds-text-zh_CN.GB2312 = <<- _END_MDOC_USAGE
blah
_END_MDOC_USAGE;
Harlan notes that some might prefer
#include ds-text-usage.$LC_AGEN
instead, and that's fine - it's a "policy" choice, and he is interested in making sure we have a good "mechanism" here.
autogen
might treat
$LC_AGEN
as slightly magical - if no value for
$LG_AGEN
is specified, we might see if there is a value for
$LC_ALL
(for example) and use that instead. And it should not be a fatal error if the requested "translation file" does not exist; in that case the base
ds-text
stanza would be used.
Naming Output Files
Some folks will want to
generate more than 1 (likely all) locale's worth of output files. This will probably require a
for
loop in the
Makefile.am
and we will need to choose a naming convention for the generated files. We may also want a way to
install a subset of these files.
Comments
as .def files are used to generate both source code and document, so any change to them will have impact on both of them:) I intend to use a consistent method with source code's
I18N process:
- describe the part need to localize in some place, for documents the best place should be in the .tpl file(autogen's template)
- generate localized content according the description and translation table(.po files)
here is my sulotion for documents' i18n:
- modify autogen template file used to generate documents, so that it know which part of .def file should be localized, and do the substition(translation) when running, for example "descrip" and "doc" field in our def files.
- construct a translation table for those need to be localized, actually it's the same format as .pot file.
- run autogen with new template and translation table and gettext, we get localized documents according current locale settings
- if we loop through all languages in makefile, it could generate localized documents in different language(except those without translation table), there is naming problem here raised by Harlan, we could name them with language code or categorize them in different directory(named in language code like the ones in /usr/share/locale)
PS. the attachment is am example that illustrates this proposal(including naming problem), it works in my Ubuntu, if you have any problems about it, please contact me via email or xchat
this sulotion involves in gettext(the command line tool, not library), but only when generating documents.
--
EricFeng - 2011-05-28