I'm looking for an explanation of the following AOSP build properties, what valid values are and how they affect the build and any related properties. I am aware of the system property ro.sf.lcd_density but I can't find any official documentation anywhere about these:
PRODUCT_AAPT_CONFIG
PRODUCT_AAPT_PREF_CONFIG
PRODUCT_AAPT_PREBUILT_DPI
This is my experience, and probably should not be the accepted answer as I'm not certain I have the whole story.
PRODUCT_AAPT_PREF_CONFIG: The "preferred" resources qualifier. This should be one of the entries in PRODUCT_AAPT_CONFIG.
PRODUCT_AAPT_CONFIG: an ordered list of the resources qualifier. This acts as a fallback in case the preferred resource qualifier does not exist.
PRODUCT_LOCALES: A list of locales that will be included. For whatever reason locales are a special case of resource qualifier.
In my case, I used this:
PRODUCT_AAPT_CONFIG := large xlarge mdpi tvdpi hdpi
PRODUCT_AAPT_PREF_CONFIG := hdpi
PRODUCT_LOCALES := en_US en_GB en_IE de_DE pl_PL pt_BR es_US
Our device is TVDPI, but since there are generally no TVDPI specific resources, I picked the next size up as preferred (HDPI). I included "large xlarge mdpi tvdpi hdpi" to allow for a fallback in case there was no HDPI resources.
Related
I am attempting to remove all references of a managed package that is going to be uninstalled that spans throughout code base in VS Code
I have using a query to find the field permissions but am wondering if there is a way to search for the reference outside of specifying the exact field name compared to the field containing only "agf" since they are all using it.
Below is the search query:
<fieldPermissions>
<editable>false</editable>
<field>User.agf_Certified_Product_Owner__c</field>
<readable>false</readable>
</fieldPermissions>
In the field, I want to be able to find and delete the 5 associated lines from multiple files if they match "agf" in any combination. Something like the below:
<fieldPermissions>
<editable>false</editable>
<field>agf</field>
<readable>false</readable>
</fieldPermissions>
With any combination of agf in the field, delete all from any file it appears in.
Not an answer but too long for a comment
You don't have to? Profiles/perm sets don't block package's delete. Probably neither do reports.
You'd use your time better by searching for all instances of agf__ (that's with double underscore), should find fields, objects... used in classes, flows, page layouts etc. And search for agf. (with dot) should find all instances where your Apex code calls their classes marked as global.
Alternatively Apex / VF pages with dependencies on package will have it listed in their "meta.xml", for example
<?xml version="1.0" encoding="UTF-8"?>
<ApexClass xmlns="http://soap.sforce.com/2006/04/metadata">
<apiVersion>54.0</apiVersion>
<packageVersions>
<majorNumber>236</majorNumber>
<minorNumber>1</minorNumber>
<namespace>SBQQ</namespace>
</packageVersions>
<status>Active</status>
</ApexClass>
Last but not least - why not just spawn a dev sandbox and attempt the delete there? If it succeeds - great. If not - it'll list the dependencies that blocked the delete. It'll be "the real thing", it'll smite you even if your VSCode project doesn't contain all flows, layouts and thus could lull you into false sense of security. I'd seriously do it in sandbox and then run all tests for good measure, just in case there are some dynamic soql queries that don't count as hard, delete-blocking references.
After delete's done - fetch Profiles / Permsets from this org and the field references will be gone from the xml.
I am developing an ePub. In the content.opf file I have to specify a series of metadata by using DC standard. For example dc:title and dc:creator.
However my book is a multilanguage book, that is, it contains two translations of the same text: English and Russian. The standard reference manual states that I can have more dc:language statements. For example:
<dc:language>en</dc:language>
<dc:language>ru</dc:language>
but it does not say how to specify the other metadata for more than one language. Consider, for example, dc:creator. I tried
<dc:creator xml:lang="en">Dario de Judicibus</dc:creator>
<dc:creator xml:lang="ru">Дарио де Юдицибус</dc:creator>
I get an error from the distribution platform validator, which states that the format of ePub is not correct. It looks like I cannot use xml:lang in dc:creator even if, in theory, that is an XML attribute that can be used with any XML tag. Same for dc:title:
<dc:title xml:lang="en">My Book Title</dc:title>
<dc:title xml:lang="ru">Название Mоей Kниги</dc:title>
Could someone who has had to face the same problem as me, namely writing the OPF for an ePub that contains a text in multiple languages, tell me what is the correct way to do it? In the standards for the OPF 3.x I have not been able to find any useful information to establish this.
SOLVED
I verified my code with one of the author of the W3C specifications for OPF and he told me that what I wrote is correct, but that some validator is not used to multi-language documents, so that the problem is the validator, not the code. I write this in case someone else may have the same problem.
If I run my play framework application with "play run" the localisation is fine. But if I do a "play dist" then use the start command, then the original English messages appear.
I have found, that if I change the classpath order in the start script putting the jar containing my messages file to the first place, then the localisation is fine.
Is there any better way to do this?
It is the same, if I copy the conf/messages to conf/messages.hu and set application.langs="hu" in the application.conf.
And stays the same, if I change my browser settings, so this is in the request header: "Accept-Language:hu,en-US;q=0.8,en;q=0.6". Still English messages (only, if they are the built in keys. My custom keys are translated correctly).
We have figured it out.
There is a custom field constructor used. My assumption was, that it is using the implicit lang parameter, but this is not the case. The lang must be given to the elements.errors() as parameter, and the current lang setting is stored in the elements.lang attribute. This is stated in the documentation, but we missed it. So the implicit lang parameter should not be used in the field template, because it contains wrong value.
The solution was this: #elements.errors(elements.lang)
#elements.input
<span class="errors">#elements.errors(elements.lang).mkString(", ")</span>
I'm using toLocalizedTime to output a date, as below
<span tal:content="python:here.toLocalisedTime(date.get('start_date'))"/>
This outputs eg. 2007/08/02, I'm just curious as to how one would alter the output so that it reads 02/08/2007
I'm not having much luck finding much info on toLocalizedTime, would someone point me in the right direction?
This depends on whether you have English selected as the site language (Site Setup >> Language). If so, then the default settings are used. You can change the defaults by dropping down into the ZMI, then into 'portal_properties', then 'site_properties'. The fields to change are either 'localTimeFormat' or 'localLongTimeFormat' depending on whether you pass in 'long_format=1' to the toLocalisedTime function.
If on the other hand, you have translations set up, the format may instead be pulled from the translation file for the locale selected. I'm not sure what is the easy way to change the format in this case (other than switching the site back to English). I guess you can register your own translation file but I've never needed to do that so you're going to have to look up the details.
Date string formatting follows the Python rules (http://docs.python.org/library/time.html#time.strftime).
Perhaps even more detail than you need:
here.toLocalizedTime()
is defined in the plone browser view at...
CMFPlone/browser/ploneview.py
which looks up the 'translation_service' utility, to call its 'ulocalized_time' function, defined at...
CMFPlone/TranslationServiceTool.py
which itself calls the 'ulocalized_time' function defined at...
CMFPlone/i18nl10n.py
As always, you can learn interesting things by grepping the source code ;-)
For an up to date answer for Plone 4.3 (after going through the source code)
These fields are now in the registry found at:
http://localhost:8080/yoursite/portal_registry
Then filter on "i18nl10n", which should give you the 4 fields you need to change.
For example, instead of writing the following:
element * .../my_branch_01/LATEST
element * .../base_branch/LATEST -mkbranch my_branch_01
I would want to write something like this:
MY_BRANCH=my_branch_01
element * .../%MY_BRANCH%/LATEST
element * .../base_branch/LATEST -mkbranch %MY_BRANCH%
Is this even possible? What is the correct syntax?
The only native way to do this in ClearCase is to use attribute within a config-spec.
According to the version selector rules, you can make a "selection by query" rule, based for instance on an attribute:
element * ...{MY_ATTRIBUTE_NAME=="aValue"}
would select the LATEST version on any branch with an attribute 'MY_ATTRIBUTE_NAME' with 'aValue' in it.
That mean you need to change the attribute value on the old branch, put it on the new branch, 'cleartool setcs' your view again, and you should have a new content based on a new version selection.
Not very straight forward, but it could work, except for the mkbranch part (which needs a fixed name).
Regarding GeekCyclist's answer, a few comments:
The solution to include a common config spec can work for Base ClearCase solution, but:
need to be in a share available by all concerned developer
the setcs is indeed necessary to Ccuses the view_server to flush its caches and reevaluate the current config spec, which is stored in file config_spec in the view storage directory. This includes:
Evaluating time rules with nonabsolute specifications (for example, now, Tuesday)
Reevaluating –config rules, possibly selecting different derived objects than previously
Re-reading files named in include rules
all the other developers need to be notified when the common included config spec file changes (there is no native notification included in ClearCase)
If you need to have one "environment" (i.e. one "view" or workspace) with a variable content (depending on a different branch), you need to define a symbolic link (or a windows subst) pointing to different views (each with their own config spec)
That way, you only have to change the link (or the path subst'ed) in order to change the config spec associated with a given fixed path.
It's been a while since I worked in ClearCase (we switched to Subversion), but if I recall correctly there is no way to do this native to ClearCase.
You could use or write a script generator that would create your spec file and then include that in the actual spec:
element * CHECKEDOUT
include scripted_file_output
Then run
cleartool setcs -current
The problem with this approach is that I believe the include spec would need to be regenerated and the cleartool setcs run whenever you change the value of MY_BRANCH.