Date

[Fale]

With this changes, dates are managed directly by the system. This way is possible to manage them in an automatic way through the different languages :).
If a date is recognizable by strtotime() the strtotime() output will be used. Otherwise the user string will be used. If the first option is used, it will be automatically internationalized based on the blog/qtranslate options.
If a date is in the future, automatically will be add "(estimated)". This string can be translated with the lang system.
If the ending date is not yet known, is possible to use "present" (case insensitive). In this case, "Present" will be shown and translated, if needed.

[benbalter]

I really like this functionality. A lot. Thanks for taking the time to put this together. i18n is not my strong point.

It's important to take a second to note that as written, this is a pretty big shift in philosophy. Right now, whatever the author puts in the from or to box appears on the front end as is. Gives the plugin ownership of that output. Think about the possible inputs:

• May 2011
• 2011
• 05-01-2011
• 2011-05
• Summer 2011

All but the last will be parsed by stringtotime() and forced to conform to the plugin's format. (e.g., even if I want "May 1st, 2011", it will be converted to "May 2011", and "2011" will be converted (I believe) to "January 2011", etc.)

As for "Estimated", again, what if I want "Anticipated" or "Expected" or "Planned" (or nothing)?

Here's my thinking:

Merge the pull request with the intention of beefing up the API calls in get_date() and moving the functionality to a filter conditioned on qTranslate being installed. That way you should (in theory), get the best of both worlds. No qTranslate, get exactly what you put in. With qTranslate, run the strings through to be translated by default, but let folks short-circuit the filter if they want.

Also, noticed a few strings that need to be given translation support which I can take care of..

[Fale]

About the 5 cases: one and four should be fine ;). For the other 3, I'm thinking ;).

About the "Estimated", "Anticipated", "Expected" or "Planned" is possible to add those words. If you put
May 2012 (expected)
nothing will be done, and the string will be printed as it is.

I was thinking about a flag in the "option" page. Something like "Auto-fix dates (suggested for internationalization)".
How do you see this?

[benbalter]

I took a stab at the problem in 2c0d510.

If possible, I'd prefer to make a decision, rather than an option, or at the very least, let the software make the decision.

Here's my suggestion:

If qTranslate isn't installed (or the user hasn't forced translation via the api hook), date is simply passed through resume_date and resume_date_formatted as per usual.

If they do want translation, the translate_date() method is added to the standard resume_date hook and takes care of everything.

I added two additional properties (and associated filters). $date_format is the default date format, when i18n'd (defaults to F Y, as per your code), and $future_signifier which is the default string to append (which is then translated). That way, developers can override both should they see fit.

Also, before stable, will make a note to memorialize all this in the FAQ, so per your suggestion, users know they can use the "May 2011 (Expected)" format to bypass this whole process.

Beyond that, just did a bit of code cleanup/simplification, and allowed either from or to to be optional (and still translate).

Give it a try and let me know if it works with qTranslate as expected?

[Fale]

I tried it with qTranslate and it does print the strings as I gave them to it. :(
I'm trying to understand where the bug is, but I haven't found it yet :(

[Fale]

Editing a position the following error is returned:
Fatal error: Call to undefined function wp_nohtml_kses() in /home/fabio/public_html/wp-content/plugins/WP-Resume/includes/admin.php on line 340

[Fale]

Hi,
I've just opened 2 pull request (in reality they were 4, since I
always pick your wrong branch, selecting master the first time and
then getting it right the second time).
The #4 does fix an admin Fatal Error. The #6 does fix the qTranslate
integration. Now is only needed to work on the "(expected)" feature,
that I had to cross since it was returning a fatal (as soon as I'll
end this mail, I'll start to work on it).
I'm writing the email also for another reason: if the system is not
able to evaluate the exact date, the hResume standard is not met since

• by default - the system assumes that the date is 1970-01-01. I think
  the system evaluation should be mandatory to all the people that would
  like to have an hResume valid output. How do you see this?

Fabio

On Mon, Feb 13, 2012 at 11:46 PM, Benjamin J. Balter
reply@reply.github.com
wrote:

I took a stab at the problem in 2c0d510.

If possible, I'd prefer to make a decision, rather than an option, or at the very least, let the software make the decision.

Here's my suggestion:

If qTranslate isn't installed (or the user hasn't forced translation via the api hook), date is simply passed through resume_date and resume_date_formatted as per usual.

If they do want translation, the translate_date() method is added to the standard resume_date hook and takes care of everything.

I added two additional properties (and associated filters). $date_format is the default date format, when i18n'd (defaults to F Y, as per your code), and $future_signifier which is the default string to append (which is then translated). That way, developers can override both should they see fit.

Also, before stable, will make a note to memorialize all this in the FAQ, so per your suggestion, users know they can use the "May 2011 (Expected)" format to bypass this whole process.

Beyond that, just did a bit of code cleanup/simplification, and allowed either from or to to be optional (and still translate).

Give it a try and let me know if it works with qTranslate as expected?

---

Reply to this email directly or view it on GitHub:
#2 (comment)

Fabio Alessandro Locati

Home: Segrate, Milan, Italy (GMT +1)
Phone: +39-348-2668873
MSN/Jabber/E-Mail: fabiolocati@gmail.com

PGP Fingerprint: 5525 8555 213C 19EB 25F2  A047 2AD2 BE67 0F01 CA61

Involved in: KDE, OpenStreetMap, Ubuntu, Wikimedia

[benbalter]

Sorry about the sloppy code. Promise to test more thoroughly next time before I commit. :)

I believe I fixed the "Expected" feature. Just a typo in the method name.

The whole API class is designed to force me to consistently prefix filters (previously some were resume, some were wp_resume, etc.). You should be able to just pass the filter name (e.g., "date"), and it will actually run ("wp_resume_date"). I added the translation filter to resume_date (not wp_resume_date), which should be fixed now.

I opened issue #7 to deal with hResume and non-parsable dates. I'll have to check the spec, but thoughts on what should be outputted?