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.

Please see the NTP Security Notice for vulnerability and mitigation details.

---

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

Internationalization and Localization (GSoC 2011)

• Student: EricFeng
• Mentors: BruceKorb, HarlanStenn
• GSoC: GSoC Project Page

Summary

The goal of this project:

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:

1. describe the part need to localize in some place, for documents the best place should be in the .tpl file(autogen's template)
2. generate localized content according the description and translation table(.po files)

here is my sulotion for documents' i18n:

1. 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.
2. construct a translation table for those need to be localized, actually it's the same format as .pot file.
3. run autogen with new template and translation table and gettext, we get localized documents according current locale settings
4. 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

• i18nexample.tar: i18n example