I'm not sure this is the right place to ask this. I would like to know how best to style parts of messages from l10n properties files. For example, my client want this message and formatting in a help window:
This is a self-assessment and comparison application.
Simplest solution would be to include the HTML tags in the messages.properties entry for this label. The problem with that is that the 40 translators that will process the messages.properties are bound to make mistakes like deleting the <, translating the attributes or styles of the HTML markup etc. Also it makes maintaining the markup and styling difficult for the devs.
Any better way to do this?
The solution I've seen typically done just uses th:utext with HTML tags in the .properties files. I would opine it does create a maintenance hassle as you mention and should be kept to a minimum.
One workaround is to create separate strings in some cases, like:
<span th:text=#{thisIsA}>This is a </span><strong><span th:text="#{selfAssessment}">self-assessment</span></strong>
However, this is error-prone since certain languages may change the order of the words. So that's not a great option.
If the HTML tags specifically are an issue, another way albeit somewhat ugly could be:
thisIsASelfAssessment=This is a {0}self-assessment{1}.
Or even
thisIsA=This is a {0}.
selfAssessment=self-assessment
But that might be confusing for the next developer reading it and may introduce the same issue you have with the 40 translators looking at it since you have curly braces. It also all becomes very tedious and generates more lines.
So in the end, you're likely best going with the simplest solution of utext.
Project-wise, you could have the initial translation done without the markup and add the markup in after they are done with a first pass at translating it. The issue may arise in the future when you need to change strings, but doing this would minimize some headache. It could make sense to keep these strings in a separate block in the .properties file so you can target them later.
Good question as I've had this issue myself.
Related
TL/DR: I have a game plan on how to do this below; however, I am wondering if my plan is going to prove to be too complicated, and what additional considerations I need to take into account before diving into building this project. Although I am not an experienced programmer, I am NOT asking for code; I am asking for feedback from experienced Word VBA programmers as to whether my entire idea/approach is one huge mistake.
I have a document "template" (not yet a template file type - I hope to create that as described below) for a report. The report is broken up into different sections:
Letter to the Client
Table of Contents
Section I
Title Page
Body
1.0
2.0
Section II
Title Page
Body
1.0
2.0
Appendix A
Title Page
Body
Appendix B
Title Page
Body
I want each major "metasection" (such as Letter, Section I, Section II, Appendices) to have different styling and formatting. This could be accomplished by having multiple styles for each metasection, e.g.:
Normal-Letter
Normal-SectionI
Normal-Appendices
Heading1-Letter
Heading1-SectionI
Heading1-Appendices
This would quickly become unmanageable.
In order to avoid users having to wade through a huge number of styles to find the correct one (and it is worth noting that if users of this report have to do this, they will likely not use styles AT ALL), it would be nice if I could have the same style name (e.g, Normal) be different depending on which section of the document it is found in. Or said another way, I would like for a document to have multiple style sets depending on the section.
The goals for the user experience are:
The user simply applies the Normal style, Heading1 style, etc, as necessary.
Registered section-specific style definitions are updated when styles are edited via the Modify Style dialog box, or other ways.
The styles are applied automatically and transparently when styles are changed, or when the document is opened, saved, or printed.
ALTERNATIVE: If automatic/transparent style application proves too difficult, execute the style-application routine with a simple command button.
My initial idea on how I might do this in VBA is:
Write VBA code (probably a class) such that there is a style registry of Normals and Heading1s, etc., for each document section.
Write a style-application subroutine which iterates through the registered document sections, selects all the parts with each registered style, and applies the section-specific style from the style registry (preserving any styling that deviates from the style definition).
Write a style-update subroutine that automatically and transparently updates the registered style definitions
The style-application subroutine executes any time styling is applied anywhere in one of the registered sections (so I'll need to tie into Events here).
The style-update subroutine executes any time a style definition in a registered section is changed (so here's another Event I'll need to monitor).
I previously asked a similar question about this topic on Superuser. The feedback I received has led me to believe that I can only accomplish the behavior I want using VBA, so I am now asking a follow-up question here on Stackoverflow.
My question is: am I making a mistake here? I have a feeling there is a better way to solve this problem (perhaps using VBA, perhaps not) than this.
Yes, in my opinion, you are making a mistake.
I have just recently finished a project where I have created a document template for a company. My experiences:
Users vary in knowledge level (obviously)
High level users don't like over-engineered files, because they can't use their own macros as they might conflict with the file's own macros, they can't use their doc properties or their own building blocks etc., as these likely won't be compatible with the macros (or at least they think they won't work, and fiddle around until they actually manage to break them)
low level users are intimidated by the automatisms, and keep avoiding them as long as they can (which means as long as their bosses don't order them to use the file), after which point they start hating the file and the work
Complex solutions like this one usually get abandoned after a few years. Eg. the original developer changes jobs, or moves to another department, and nobody understands the code enough to keep managing it (especially if it is not a well-documented, well-written code, which it won't be, as you are not an experienced VBA programmer).
The developer (you) will be inundated with (sometimes false) bug reports and questions and minor change requests, which gets really annoying after a few weeks (trust me on that :) ). They won't dare change even a font size without consulting you, and in the end, they will ask you to do it. Or, even worse, they try to change something, break it, and then tell you to fix your bug.
Your users would have to remember to use section brakes or other kinds of indicators to indicate the next section. This will seem too much for some, too complex, and if they accidentally remove a section indicator (which they inevitably will), all hell brakes lose, and worst of all:
Undo function will be disabled after each macro run. This, to most users, is a disaster. You don't do that to your users.
So I would say don't go down the macro route. Don't use Doc properties, that didn't work at the company I was working with. (Actually an IT company, with mostly high-level users :) ) The high-level users will create and use their own doc properties, for others, it is just a hassle. Bookmarks get constantly deleted, so no-go either.
My advice:
Use styles. Users will learn to use them quickly.
Get a decent document design. Having 4 different sets of title, heading and normal styles in one document is really unprofessional. Consistency is important, especially as this seems to be a letter to you clients. (Yes, I know, your company is different and your bosses are dumb and this is a special case and and and ... Just saying, talk to a designer, and get a professional look for your template.)
You can manage the Style gallery (Home tab, centre) drop down list on a template basis - so your template will load the used styles into the dropdown at the top, and remove everything else. This works really good, and even as much as 20 styles is manageable, if they are well-named.
Use building blocks: title pages, tables, pre-written and formatted Quick parts (legal mumbo-jumbo, company introduction, contacts, etc.), headers and footers...
And, if you want happy-happy and cooperative users:
After creating a blank template, create a full template:
Fill up a document template with texts, pre-written paragraphs, pre-written titles, so they will only have to click and rewrite, without the need to format or bother with styles and Cover pages and the lot
Educate the users: 2 sessions of 1,5 hour Word class can go a long way. It is a must.
Long post. One last thing: creating a complex Word template, you will be sailing a sea of Word bugs and annoyances. Even without writing macros, this won't be a walk in the park. (I for example gave up on making my TOC work in Office 2013, as after 3 days and 10 versions, it still kept on creating a maximum sized extra paragraph whenever it was inserted. Only in W2013. Still no idea why, but I let it go.)
Whatever you decide to do, best of luck, and have a lot of patience! :)
In short, this is bad web development and UX:
But solving it by using CSS3 word breaking (code & demo) can lead to an 'awkward whitespace' situation, and strange cut-offs — here's an example of both:
Maybe it's not such a big deal, and the UX perspective of it is here, but let's look at the semantics of one of the solutions:
You could ... use the <wbr> element to indicate an optional word
break opportunity. This will tell the browser to insert a line break
as necessary to flow onto a new line inside the container.
The first question: is using <wbr> semantic HTML? (Does it at least degrade gracefully?)
In either case, it seems that being un-semantic in the general sense is a small price to pay for good UX functionality.
However, the second quesiton is about the big picture:
Are there any schema.org (microdata/RFDa) ramifications to consider when using <wbr> to split up an email address? Will it still be valid there?
The wbr element is defined in the HTML5 spec. So it's fine to use it. If it's used right (= according to the definition in the spec), you may call it also "semantic use".
I don't think that there would be any problems in combination with micordata/RDFa. Usually you'd provide the URL in an attribute anyway, which can't contain wbr elements of course: foo<wbr>#example<wbr>.com.
For element content I'd guess (didn't check though) that microdata/RDFa parsers should use the text content without markup resp. understand what is markup and what is text, otherwise e.g. a FOAF name would be <abbr>Dr.</abbr> Foo instead of Dr. Foo.
So you can bet that microdata/RDFa parsers know HTML ;), and therefor it shouldn't be a problem to use its elements.
I'm building an IOS application, and would like to offer the user the ability to use macros for different aspects of the system.
For example, I might have a simple macro this this:
{include name="some name" pre="some it of htmk" post="some other bit of html"}
That would include the contents of the item named "some name" in the body of the document the user is working on.
or I might have something more complex like this:
{notesForTag name={ListAllTags pre="some bit of html" post="some other bit of html"} pre="..." post="..."}
Which would list all the documents in the system grouped by tag.. the ability to add on data (like html) at the beginning and the end of each tag returned would allow the user, for example, to format the response as a table, or use particular styling, etc.
Conceptually, I know how I want this to work, but I'm wondering if there are any macro construction and processing best practices out there that would help me on my way. Anything geared towards Objective C / IOS would be most helpful.
Edit: To add some clarity here, what I'm looking to discover is an efficient and accurate way to parse something like this. Having parsed things, I think the rest will be fairly straightforward.
Thank you.
NSScanner would probably work well for parsing something like this, perhaps with a recursive function to allow nested macros like the second one. You may also want to consider using XML to represent your macros, which would allow you to use NSXMLParser to parse it, so you only have to worry about the content and not the structure.
I have a webpage where i have to allow the users to customize their header and footer.
i.e. I should store the Users header and footer HTML and should dynamically add it to the webpage. I have two ways of storing in database and storing in a files. Please suggest me which approach is better.
Solution with files get messier with time. With databases, it is easier to scale.
With databases, you can add bookkeeping fields (like last-modified, tags, or something else depending on your need). Backup is easier also perhaps.
With files, you have to worry about directory structure (having too many files in single directory is not good), permissions, etc.
If you are worried about efficiency, stop worrying :). MySQLqueries are pretty fast especially with the caching mechanisms/modules in apache.
Ther's not a better approach (there are pro and cons in general) but in this specific case I would store these snippet as a file because you have less complexity for sure (because you don't need to query a database and fetching result) and you don't relies on database connection for including header and footer
If you're using .Net you've something called Portals which does the same thing. There are things like master pages also that you may want to read. But all these are in .Net. Even if you're not doing this in .Net it'd be time consuming to handle all this stuff on your own as you need to take care of cross-site scripting and a few other issues.
Check the platform for features that you're working on to find out if this is possible by them. (Let me know the platform that you're using so I may help in that). Also, if the changes are just cosmetic you may store just css settings instead of complete html.
Finally it'd be better to use sql if the number of changes to store are more than 100 as the complexity will bug you down. But if you're fewer users and don't expect any scaling up then sure go for a file system.
:
Here are a couple of links for understanding portals and web parts in .Net:
http://msdn.microsoft.com/en-us/magazine/cc300767.aspx
http://msdn.microsoft.com/en-us/magazine/cc163965.aspx
I'm looking for a package to typeset SQL statements in LaTeX. So far I have heard of listings and lgrind, are there any other suggestions?
[edit] Added requirement: I'd like the package to be able in intelligently insert page breaks, so that where possible statements do not span multiple pages. Still reading documentation, so it is possible that either of the a/m are able to do this already- Please let me know if this is the case.
Related: question
I use the listings package, but mostly for snippets. I haven't needed to worry about page breaks in general. One of the great things about listings is the high degree of flexibility available. For instance, I don't capitalize my SQL, but I can print my listings with capitalized keywords:
\makeatletter
\newcommand{\lstuppercase}{\uppercase\expandafter{\expandafter\lst#token
\expandafter{\the\lst#token}}}
\newcommand{\lstlowercase}{\lowercase\expandafter{\expandafter\lst#token
\expandafter{\the\lst#token}}}
\makeatother
\lstdefinestyle{Oracle}{basicstyle=\ttfamily,
keywordstyle=\lstuppercase,
emphstyle=\itshape,
showstringspaces=false,
}
And define more keywords as I need them:
\lstdefinelanguage[Oracle]{SQL}[]{SQL}{
morekeywords={ACCESS, MOD, NLS_DATE_FORMAT, NVL, REPLACE, SYSDATE,
TO_CHAR, TO_NUMBER, TRUNC},
}
To make use of these definitions:
\lstset{language=[Oracle]SQL,
style=Oracle,
}
If I were to print out larger pieces of code, I'd either not worry about page breaks or write a preprocessor to divide the code up before passing it to LaTeX.
You want to use the listings package. Is there a specific thing you want to do with it, or are you just asking which package works best in general? I've never encountered any big problems with listings, though getting it to do Exactly What I Want is sometimes tricky (it's LaTeX; to expect anything else would be folly).
Edit (to address your edit): intelligent page breaking might be problematic; it's certainly beyond my abilities. listings might be able to do it with explicit markup (escape to LaTeX and insert a negative page break penalty at appropriate place; likely macro-izable), but I don't think listings can do it automatically, and I doubt LGrind can do it either. You might have better luck searching or asking on a LaTeX-specific list (comp.text.tex on Usenet is a great place to try), but page breaking in TeX has never been as good as line breaking, and so I wouldn't hold out too much hope, unfortunately.