EditWYSIWYGAttachPrintable
r4 - 2011-05-18 - 03:31:26 - HarlanStennYou 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)

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

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-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 
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

 
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-2020 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