r6 - 2011-05-28 - 16:15:48 - EricFengYou are here: NTP >  Dev Web > GoogleSummerOfCode > GSoC2011InternationalizationAndLocalization
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)


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:


Date Task Description % Done
2011-04-25   Accepted student proposals announced on the Google Summer of Code 2011 site. DONE
2011-04-27 discussion and planning communicate with mentors/ntp developers, to fix the project border and plan.  
2011-05-07 prepare the data to translate extract all the strings in the program, and classify them according to some priority. we will know which must/need to/no need to be localized, the following work and all localizations will benefit from the result of this step;  
2011-05-24 Start i18n work determine the i18n solution for NTP. if we don't want to import depency to other libraries, design a new translation engine for NTP; part of the coding works;  
2011-06-07 code change do most of the code change work; I would be busy with my final examination of this semester during this period(the exact date is still unknown now) :(  
2011-06-13 exam week...    
2011-06-21 finish goal 1 finish the code change, and test the change carefully. after this week, the goal 1 should be done  
2011-06-28 start localization collect the documents to be translated, start to localize the strings collected from program before, submit mid-term report  
2011-07-15 Mid-term evaluations Mid-term evaluations deadline  
2011-07-15 finish program's Chinese l10n work the goal 2 would be done before now, continue my localization work, and invite some one to do the localization for another language; after this period, the program's Chinese localization should be done.  
2011-07-26 document translation test and adjust the localization work; translate the documents; get the result of the localization of the other language.  
2011-08-15 Wrap-up Suggested 'pencils down' date. Take a week to scrub code, write tests, improve documentation, etc.  
2011-08-15 Wrap-up finish the translation work, test previous i18n work with the two languages' l10n data  
2011-08-22 Firm 'pencils down' date. Mentors, students and organization administrators can begin submitting final evaluations to Google.  
2011-08-26 Final evaluation Final evaluation deadline  
2011-08-30 Code samples Students can begin submitting required code samples to Google  

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 

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 
  ds-text-zh_CN.GB2312 = <<-  _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 

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.


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

Topic attachments
I Attachment Action Size Date Who Comment
ziptar i18nexample.tar manage 20.0 K 2011-05-21 - 18:15 EricFeng i18n example
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r6 < r5 < r4 < r3 < r2 | More topic actions
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback