We're building a multi-language Drupal stack and one of the concerns we have is that our payment processor is going to have to send back some information to us. We've been able to narrow this down so that the strings they're sending back look like
<country code>-<number of months>
so we can easily translate that into any number of languages, except English.
t('FR-12') is all well and good if we want to translate that into a french description, but because there's not an English language a similar string like t('EN-12') is not translatable.
Similarly for the generic string: #API_Connection_Error
This sort of generic string approach seemed really compelling to me at first but it seems to not work in Drupal. Do you have any suggestions about how to translate generic strings like this into both English and other languages?
Thank you, I've been looking through Google all morning.
I see two ways to achieve this at the moment:
You could just replace the default English language definition with a custom version. That way, you can 'translate' selected English strings just as with any other language. If you have configured locale module to fallback to the original string in case of absent translations, you can just add your special cases as translations to your custom English version, and everything else will use the original English version.
Take a look at the String Overrides module - it allows you to define custom overrides for any string that gets passed through t(), with separate overrides per language, including the original English.
I'd use the second option in your case, except if the number of 'external' strings is very high. See the first if clause of the t() function for the mechanism used for the overrides (lookup in language specific Drupal variable arrays).
Note that the String Overrides module just adds admin UI pages to configure those Drupal variables in the Backend - you could add/adjust them yourself as well (e.g. from a custom module).
Related
I want to post an alien artifact to my server.
Do I write type="alienArtifact"
or type="alien-artifact"
or something completely different?
I looked here https://jsonapi.org/format/ but is only deals with simple types, "objects".
JSON:API specification is agnostic if you use kebab-case, snake_case or camelCase for field names but it comes with a recommendation:
Member names SHOULD be camel-cased (i.e., wordWordWord)
This recommendation was change in October 2018. It was kebab-case before. Therefor many articles about JSON:API specification and documentation for libraries are still using kebab-case. These arguments were given as main reasons for this change:
camelCased names can be used directly as identifiers in almost all programming languages, making json:api easier to get started with and to work with over time. Dasherized names are usable as identifiers pretty much only in Lisps.
camelCased names are the most common convention in the JS community, and JS is the biggest user of JSON:API
camelCased names are slightly shorter than dasherized (or snake-case) names, which could help with url character limits in
the case of complex filters or other types of complex queries
(e.g., some GraphQL like “deep querying” feature) that we might
serialize into urls in the future.
You could find more details about this change in the appropriate pull request.
I have a global resources file for different languages:
Resource.resx
Resource.de-DE.resx
Resource.ro-RO.resx
For the most part, all the strings in Resource.resx have localized versions in other languages as well.
However, I have certain strings that should only exist in Resource.de-DE.resx but not Resource.resx. When I try to use them in my code:
GetGlobalResourceObject("Resource", "Personal Identification Number")
I get an error that says Cannot resolve resource item 'Personal Identification Number'. The string still gets localized properly when I view the page in German because it's present in Resource.de-DE.resx, but because it's not in Resource.resx, I get this error in Visual Studio, and I'd like to get rid of the error.
How do I work around this so that I don't get this error message? Should I move the local-specific string to another resource file?
The whole resource fallback approach really assumes that all strings are present for the base language.
I imagine you have this scenario because you implemented some feature that only applies to German and you don't want to add unnecessary resources to your base language as these will increase the localization effort for languages that don't need it.
One solution would be to create a separate local resource file. And either only translate this one into German (and not other languages) or make it a base resource (without the de-DE language code but still with your German strings in it).
Another solution (if you can't create a local resource file and for some reason can only use global resources) would be to add those extra entries to your base global resources (Resource.resx) and make it obvious that you don't want these translated. For example make them all blank strings and use the Comment field to explain that these strings are for German only. Not very nice.
I just replicated your scenario and it works fine. just create another resource file containing local-specific strings. hope this helps :)
i use customfiel php code inside one of my views to translate a string since 2.x of views is bad at localization. i use the following php code:
echo t('Watch Video');
but the string does not appear in the "translate interface" section.
thanks for your help.
lukas
The accepted answer is wrong, as the localization script is not scanning anything. The string is registered in the translate interface as soon as it gets passed through the t() function for the first time in the non-standard language.
Therefore, for translation it doesn't matter if the code you are writing is eval'd (interpreted from the database) or exists in the source. Obviously good practice would be to keep code in files where it belongs.
This blog post describes what needs to be done to get your strings into the translate interface.
The localisation database is built by scanning the source code, looking for instances of the t() function (and Drupal.t() in Javascript).
If the code in question has been entered into a text box in the Drupal admin area, then it isn't in the source code, so it won't be picked up by the localisation process.
For this reason (and others), you should put as little code as possible into the admin text boxes. There is usually an alternative way to achieve the same thing, but even if there isn't, you should reduce the code to a minimum -- best practice would be to have nothing there except a single line function call: have it call a function, and write the function code in your module or theme. That way it will be parsed when you run the localisation.
I've noticed that it is a common functionality within public sites to change the name of uploaded pictures to a long, 'random', alphanumeric string. This is good for privacy etc.
I can't find a module within Drupal that achieves this, and was wondering if it was possible. This would need to operate before modules like ImageCache.
???
I think there're no modules that does exactly what you're looking for, but i can suggest a way to achieve this using code. There's a module called filefield_paths which makes you able to change the name of imagefield files with a token, provided by the token module.
Looking into the code of this module you can see how it works and make your own small module to achieve the same result with an alphanumeric string.
In detail, the function you're looking for is here, at line 457.
I can't provide a directly working solution as I need time to write and test the code, however this is a very good starting point.
I'm adding additional languages to a Drupal site that I'm building.
Getting the translation of content working is fairly easy using the Internationalisation module.
Yet, simple things such as date strings, i.e. day, month and year aren't translated.
I would expect simple things like this to be some of the first things to be translated.
Am I missing something?
For text to be translated, each module needs to pass display text through a specific function (named 't()') which allows the text to be translatable.
It's likely that some module writers are better at doing this consistently than others.
I found the solution to this in the end.
It came down to knowing what to search for in the translate interface admin section.
I was looking to translate month names into different languages and so search for strings matching 'November'. This always came up with nothing.
It truned out that I need to search for 'month'. This then allowed my to add translations for all of the month names and also other date related translations.
Very frustrating the effort required to find that out!